Ask HN: Do Agile 'Sprints' Benefit Software Developers?

[rickcarlino]

I've been revisiting Agile principles through "The Art of Agile Development" lately. While it's a valuable refresher, I'm having difficulty reconciling the concept of 'sprints' in Agile after 11 years in the industry. My observation is that significant time and energy go into sprint planning, discussions, and subsequent introspection when things don't pan out. Agile sprints, to me, seem reminiscent of calorie counting - good in theory but more often failing in practice.

To clarify my intent:

1. I'm seeking input primarily from software developers rather than project managers, executives, customers, etc. 2. This is not an indictment of Agile overall. I endorse limiting work-in-progress, decomposing larger tasks, continuous delivery, and scheduling improvement time - all achievable without sprints. 3. When I refer to "Agile", I'm talking about methodologies adhering to the Agile manifesto.

To be clear, I don't believe sprints inherently benefit developers, and it feels as if the Agile community hasn't adequately consulted engineers on this topic. When I've asked developers about their feelings on sprints (excluding WIP limits or task decomposition), the responses lean towards indifference or opposition. Is the effort of sprint planning worthwhile when faced with such apathy?

Common pro-sprint arguments I've encountered include:

1. Incremental improvement/Faster feedback loop. However, sprint planning seems overly complex, with most of the book dedicated to explaining a convoluted system and potential pitfalls. 2. Early value delivery. But we're in the era of CI/CD, where deployments can happen multiple times a day. Are sprint deadlines just relics of a time when physical software delivery was necessary? 3. Autonomy. I'm not sold on this either. Autonomy for developers is often overstated. We're not pursuing hobbies or creating art; we want a drama-free, predictable, and coordinated work environment where we're respected. Autonomy, especially technical, is important, but it's not the only thing that matters on a software team, and two-week Jira ticket batches don't necessarily provide it.

My reservations include:

* Overcomplication, with an entire industry of trainers, books, and seminars evolving around it. Over time, sprint discipline often deteriorates or transforms into something less Agile.

* Lack of relevance for teams practicing CI/CD.

* The creation of artificial deadlines leading to overtime, burnout, and, eventually, high staff turnover.

* Inability to handle reality. Interruptions and unforeseen tasks will occur. The database may malfunction, revealing an architectural issue requiring immediate attention. While frustrating, these could be managed with stricter WIP limits.

* Contradiction of the Agile manifesto's "Responding to change over following a plan". Sprint planning can degenerate into "micro-waterfall".

After substantial reflection, I'm left with these thoughts:

1. Most benefits attributed to sprints could be addressed through strict WIP limits. "The Art of Agile" disappointingly provides only cursory coverage of continuous planning methodologies (like Kanban, Scrumban, etc.), recommending most organizations adopt a sprint-based approach without further elaboration. 2. If sprints offer any advantages, they aren't for the developers. I've seldom encountered developers who genuinely enjoy sprints or would miss them in a sprint-less model.

Do any fellow developers here actually enjoy conducting sprints? If so, why and how do you make it work?

And if any of the book's authors frequent HN, your insights would be appreciated. The book was excellent, barring the points mentioned above.

[fidotron]

Capital 'A' Agile has become a total anti-pattern, and the most revealing signs of this are the two-week sprint, excessive meetings, and lack of technical leadership.

By far the most productive teams I've worked with have been on six week iterations, with an at least approximate idea of what they're supposed to achieve in the next 90 days. One week out of that six is basically given over to demo, retro, and working out what the next one should achieve, but there is enough slack in there to accommodate the inevitable ups and downs, which two week Agile/Scrum pretends is not a thing. The lead developer is almost entirely focused on integrating the work of the others, and building strategy for the next iteration with product/marketing and the other team leads.

The other incredible tendency of highly productive teams is a lack of communication . . . because they don't need it. It may be more accurate to class this as a lack of noise, and clarity over what needs delivering. (i.e. product and the leads have done their job). I used to have to visit different teams in many locations, and you could tell how productive they were just by how quiet it was, interrupted only with the occasional "Dave, you broke the build!"

[regularfry]

And that's great if your organisation has an attention span resembling something other than the usual squirrel on crack. The failure mode of iterations that long in my experience is incessant "can you just take a look at X, we need it for next week" interruptions that balloon out to consume the team's attention. With a 90 day iteration you can't say "let's get that into the next sprint (and leave me alone until then)" as often as you can with a two week or a one week sprint.

[bick_nyers]

I am definitely more productive on the 6 week cycle, the 2 week cycle was too much overhead and friction for me, however I do recognize that some individuals (who were more senior than me) were more productive after our org. transitioned to the 2 week cycle, although I suspect this was more a result of higher oversight/scrutiny in their day to day more than anything.

I tend to view the work that I do as more engineering than it is development, frequently having to pull out the paper and math it out, so I think the problems I tend to work on are just fundamentally more difficult to corral into 2 week estimation chunks, but that could just be ego talking. When I started making investigation/research its own estimate that helped a bit. I think it's harder to investigate, justify, and perform significant refactors (or rewrites) on the 2 week sprint cycle, but not every team needs to do that all the time.

[gardenhedge]

How does a 6 week cycle work for planning? We do 3 weeks but each HOUR has to be assigned to a developer which obviously isn't accurate.

[PaulHoule]

Positive: The alternative to sprints is frequently no process at all, not the strawman waterfall. If you can't plan two weeks of work there is no way you can plan six months work of work. Sprints mean that conflicts get surfaced regularly and not "kicked down the can" for eight months. Teams that don't release regularly don't know how to release. so they'll plan to spend six months developing something and think they'll release in six hours and end up spending another six months making a release.

Negative: If you miss a sprint with something business critical you can turn one day late into two weeks late. This process can cascade, particularly in larger organizations that have multiple teams on their own sprint cadence, that is, something that blew one sprint can blow two or three sprints instead. Conflicts surfaced by frequent sprints frequently reveal that people in an organization don't trust each other, which is a much more important problem than how you plan, schedule and structure work. (Maybe that would be good if people did something about the trust issues)

--

I'd say that (1) Kanban is the most fundamental practice of software management (well-defined work units and limited WIP) and (2) you have to release frequently so you don't forget how to release (continuous delivery) Estimates are one of many features you can add to Kanban, the value of those really depends on the project. I've worked on projects where I could quickly make a list of items to do, plan out items like "add first name field to form" in 10 minute increments, add it all up and consistently plan week-long projects with 10% accuracy. I've worked on others where it was debugging, understanding existing code, research, and resolving circular situations and in those cases it is the opposite.

[JohnBooty]

     The alternative to sprints is frequently no 
     process at all, not the strawman waterfall.

Yeah. I see criticism of agile/sprint/Scrum practices all the time and I just think: to what are these people comparing these practices? Developing a solo hobby project where there's no collaboration, scheduling, or management to worry about?

My experience over 25 years in this industry has been that it's a fairly chaotic place, filled with meetings and management and overhead. Every shop, manager, and team generally had its own ad-hoc and ever-shifting "process" or lack thereof.

I find that Scrum, while highly imperfect, is generally a step forward over that mess.

    I've worked on others where it was debugging, 
    understanding existing code, research, and resolving 
    circular situations and in those cases [estimation
    is impossible]

Yeah. The only resolution to this is a healthy respect for the time it takes to produce an accurate estimate. That process must be viewed and respected as a separate task, with an according amount of time allocated to it.

This is actually a fundamental concept of Scrum: https://www.agile-academy.com/en/agile-dictionary/spike/

But in my experience, teams absolutely shit the bed when it comes to this. Management wants estimates but does not want to allocate the time needed to come up with good ones.

[taylodl]

^^^ This here everybody!

The much bemoaned waterfall is not a development methodology, it's a project management methodology. The developers had no process at all. That's an important point missed by developers who've never known anything other than agile development. From a developer's perspective it's not agile or waterfall, it's agile or nothing at all (typically). Agile, with its warts and all, is far better than nothing at all.

[Sohcahtoa82]

When I first started coding professionally, I thought sprints were stupid. We've got a backlog that will easily take us a year to complete. Why bother with organizing them into 2-week sections? Why not just finish a ticket, take the next one off the pile, and start working?

Over time, I learned that time-boxing your work creates short-term goals, a slight sense of urgency, and some accountability. Otherwise, it's easy to just look at the huge lists of tasks and think "Well, I'm expected to take a year to complete all these, and during that time, more work will be added to the pile, so I can just take my time" and become complacent.

That all said, sprint planning is impossible to get perfect, especially with an incompetent manager that fails to recognize patterns in point assignments. Consistent underestimations on the number of points the tasks are can look like people are underperforming. Consistent overestimations look like you have a team of rock stars.

[2023throwawayy]

> slight sense of urgency

This is my biggest beef with agile. The urgency is false, stressful, and unnecessary.

If you're always in a "sprint" you're never actually sprinting. No one can sprint forever.

[jwestbury]

> We've got a backlog that will easily take us a year to complete.

To me, this is actually a great argument in favour of 2- to 4-week sprints. Long backlogs are psychologically demotivating. Finishing a task only to find that the backlog is just as long, or -- worse, and more likely -- longer than when you started is just so depressing.

Sprints give a small, subtle, but real psychological boost from routinely completing achievable workloads. It's when you overload sprints and can't possibly complete them that they start to break down. From a psychological perspective, you should usually complete all the tasks in a sprint. Not always -- but most of the time.

Of course, people who advocate for 6- to 8-week sprints also get this benefit, but, from my perspective, there's too much chance of having to change your plans partway through. The benefit of a shorter cycle is that it's easier to pivot everyone to work on something new. By way of example, my team at my previous employer was building a new service, and we discovered about halfway through that we had a design flaw that would prevent us from surfacing the level of detail we wanted for API errors. On 2-week sprints, we were able to use half of the next sprint to change our error handling across our entire code base. Sure, we could have done that anyway with longer sprints -- but then why bother having concrete plans at all, when you know they're likely to change?

[cliff_badger]

Isn't the task itself time boxed by the points you assign to the story?

> "It is a 2 point story, why have you taken three weeks to complete it?"

[icedchai]

After over a decade of this, I'm convinced "agile" (scrum, really) was created to provide more jobs for product managers and create fluff roles like "agile coach." It may have more value for less experienced teams. More experienced developers will become frustrated by the ceremonial nonsense. I prefer the kanban style.

[wpietri]

Yeah, I think this is Scrum in specific. Unlike the other Agile methods, it had a revenue stream through certification. At the time I was like, "Hmm, something doesn't seem quite right to me, but I'm sure the best ideas will win out." I was very wrong. C.R.E.A.M., etc.

[intelVISA]

Much how we all fear Windows: an MBA's worst nightmare is nerds hogging all the good tech jobs.

If a few adjacent roles get invented for a friend so be it, why spoil the party over a few implementation details?

[sys42590]

I've worked agile for quite some years now. Please repeat after me:

1. The sprint goal is not a contract. The mental and physical well being of the developers always takes precedence over the sprint goal. The sprint goal is merely a guidance.

2. Not completing all stories at the end of the sprint should not make you feel bad. A sprint is always filled using estimates which never will be correct, and are often way to ambitious and not considering severe issues.

3. Retrospective meetings should primarily allow developers to say how they could work better. It's not an occasion for the the product owner or the Scrum Master to belittle developers for mistakes and missed goals.

[agloe_dreams]

lol on #2: We had a funny situation where leaders were mad that tickets were getting carried over every sprint. We would then say that the velocity works out to the original planned velocity, the reason tickets would get carried over was that the devs would complete their tasks, then pull in tickets while the tasks went to QA for verification. Next sprint's ticket that would get pulled in would get done when it was supposed to: Next sprint.

The leaders were like "Why are you pulling in tickets you can't complete!?!" Which led to the hilarious exchange of trying to explain that they stated that devs can only work on tickets pulled in, but because QA happens before the ticket gets marked as done, the only way no work flows over is if the dev, after handing their last ticket to QA, sat on their hands for two days. They just couldn't wrap their head around it.

[thiht]

> The sprint goal is not a contract

I kinda disagree with that. We recently switched to a sprint mode « undercommit, overdeliver ». The objective is to not commit to a lot for the duration of the sprint (ie. something we 100% know we can achieve), but we commit strongly to it. And this gives us time to handle production issues if any, or to deliver on « surprise » features of we have time to kill, or work on DX, CI, etc.

We need this « strong commitment » because we’re an early stage startup, and our sales need to know exactly what to sell to the clients, what will be available later this week.

We also take 1h every Friday to demo our work, _deployed in prod_. No demo in local/dev.

[jwestbury]

> 3. Retrospective meetings should primarily allow developers to say how they could work better. It's not an occasion for the the product owner or the Scrum Master to belittle developers for mistakes and missed goals.

When I was running retros, I created a document which recorded reasons tasks weren't finished. If you had more than 1-2 points left at the end of a sprint, you edited the doc, and either added a new reason, or just increased the tally on an existing reason. The doc didn't have edit history enabled, so it was (mostly) anonymous.

We'd review it every retro, and look for ways we could improve. A huge problem was not accounting for personal issues. We had people who were trying to take an entire normal load of tasks during the week when they were moving to a new apartment. We had true unlimited time off at this company, so there was no reason not to just take a day off. So, new explicit guideline: Take time off for your personal life. Stop trying to cram in a full week's work when you know you'll be distracted. The team will get by fine without you, and you'll be happier when you come back.

The trouble, of course, is that these sorts of things require a high level of respect amongst the team, and sometimes that's missing. So, really, you need to work on culture before you can adopt these tools.

[bick_nyers]

Sounds like every team also needs a therapist to do agile correctly.

Only half joking!

[cosmotic]

It's remarkable how many people hurt themselves and their teams by considering sprint goals as must-complete. "We must complete the work we committed to!"

[dsm4ck]

Hello it's me a software developer. In my experience sprints can be beneficial when managing executives- they understand only so much can fit into 2 or 3 weeks, when you get into months the temptation is too great to keep adding tasks. I also find it useful to avoid the developer temptation to do major all at once re-writes that involve a total changeover deployment day. Instead force developers to pick off smaller parts that can go live (and thus actually get used) sooner. Similarly, sprints challenge developers to think of what they can get done and show to stakeholders quickly and get feedback. All that being said if the executives want to operate on totally fixed deadlines and ever expanding must haves for phase 1, sprints will not save you.

[perrygeo]

IMO sprints are a barely-adequate substitute for a coherent vision with priorities. In a chaotic (dysfunctional) business environment where things change on a whim, sprints serve as a firewall to provide a few days/weeks of focus.

If everyone on the team is aligned and knows what the priorities are, sprints are rarely needed. When you do sprint, it's reserved for real emergencies. You don't need to play games to carve out time for X because everyone agrees that X needs to get done. Then when X is done, you move onto Y. Serialize. I won't say it's the only way to build software, but this method almost always produces a superior quality product compared to arbitrarily carving up tasks and trying to bin-pack them into sprints.

[bick_nyers]

One advantage of agile sprints that was pitched to me when the company I worked for was converting from 6 week cycles down to 2 week cycles was the power of this firewall and priority system. Customer Support giving you a hard time on this feature? Point them to the card and say it's in the next sprint.

How I feel now about that firewall now? I'm looking for a company that has a competent technical dictatorship in command.

[edkvmn]

How will this approach work with larger teams?

[logicalmonster]

You might end up coincidentally liking some parts of these software design methodologies like Kanban, but they generally aren't intentionally implemented to maximize developer happiness. For me, even the name "sprint" just instantly pressures me to feel rushed in my work and I hate everything about this religion.

These methodologies are designed to be a "good enough" default way for non-technical managers to organize and manage projects in a domain they don't really understand.

Imagine how confusing going to the mechanic is when you don't really understand cars. You're constantly left wondering if he's bull-shitting you about the cost and effort involved in a repair and if any progress is being made and work is actually being performed. So I get why this needs to exist, but I understand that it's not about benefiting the developer.

[jamesdwilson]

As a customer of this auto shop, I insist that there will now be mandatory 15-minute standup meetings every morning where the mechanics must provide me detailed updates on what exactly they did the previous workday and what they plan to accomplish today. I better hear more than just "worked on car brakes" - I want specifics!

We will also have two-week sprints with clear repair commitments that get tracked on a big visual board. If everything isn't completed by the end of the sprint, the mechanics will need to stay late and explain to me why not during an excruciating one-hour retrospective meeting. I don't care if these nonstop status reports, sprint planning sessions, standups and retrospectives frantically disrupt the mechanics' workflow. As the customer, I deserve to know what work is happening to my car at all times! Sure, my neurotic Agile mandates may cut actual wrench time in half while accomplishing nothing. But I can't blindly trust these mechanics' expertise - they need to recognize this agonizing process is for their own good, even if they hate it. I'm the customer so we'll do Agile repairs my way, no matter how much it impedes progress!

[agloe_dreams]

Some of the irony of this is that the actual PM should be more like a mechanic shop manager rather than the customer. One of our current issues is that we got a new PM who is, well, as you explained above. The hardest part is for them to even write sensical tickets. They can't figure out what is BE or FE work so their tickets mix multiple items while the company bans sub-tasks that devs make.

All that said, I'm 80% sure the comment you made about sprint making it feel rushed is directly noted in Basecamp's Shape Up, which honestly is a great way to run small projects where results are more important than metrics.

[JohnBooty]

    For me, even the name "sprint" just instantly 
    pressures me to feel rushed in my work and I 
    hate everything about this religion.

While I think Scrum is a small step forward relative to the chaotic nightmares I've generally experienced in this industry, I wholeheartedly agree with this criticism of the term.

"Sprint" makes zero sense as a term. By sheer definition, in the real world you cannot sprint all the time. In fact you can only sprint for a very short time. Perhaps less than 1% of your waking hours.

And yet, in agile, we are supposed to be "sprinting" all of the damn time. There is only sprinting. There is nothing else but the sprint.

Dumb and probably harmful choice of terminology.

[noodle]

Modern corporate Agile isn't the same as Agile Manifesto Agile. Even though they have basically the same name, don't mix the two up.

Sprints are one tool in your toolbox. Use them when it makes sense to do so.

I view them as most helpful around scope limiting. The goal is working software of some sort by the end of the sprint. That requires you to think about the problem at hand and how to break it apart such that you can achieve that goal inside the sprint. Some work doesn't require this boundary. Some work does.

[freedomben]

> Sprints are one tool in your toolbox. Use them when it makes sense to do so.

This sounds great in theory and I would totally agree (in theory), but my experience has been that it's the PMs or executives or higher managers that make the decision, regardless of what the engineers think. In fact, most of the times I've seen sprints pushed back on it ended up in bad feelings and unintended offense taken by PMs. In the end nothing chnages, except that the engineer who "stirred the pot" loses favor in the eyes of management.

If it was up to each developer or developer team, I would agree, but in reality it rarely is.

[mydriasis]

I like sprints because they're discrete. We agree to a certain bit of work that can get done in a certain period, and we do our best to complete it. It helps us to think about breaking up our tasks, and how tasks can be broken up. At the end of the sprint, we get to take a bit of a breath, and prepare for more upcoming work.

Kanban style means that it's just a marathon. There's no time to stop and take a breath, there's no time to celebrate anything that gets done, because the workstream is just infinite instead of divided.

That's my two cents, anyway.

[perrygeo]

The flipside of course is that they HAVE to be discrete. My issue with sprints is that they arbitrarily reduce the solution space - instead of asking "what's the right way to do this?", you ask "how much can we hack out in 2 weeks to show progress?". By putting a time/complexity limit on the work you choose to address, you are de facto ignoring any potentially high-impact work that doesn't fit into your sprint structure.

Performance optimization, bug fixes, architectural changes, dependency/infrastructure updates, developer tooling, database health, etc are rarely, if ever, prioritized in a sprint-centric workflow. Yet we know these things to be absolutely vital to the success of software.

[BigglesB]

Yup, I'd agree with this. I enjoy the "cadence" of working with a team in sprints. In a previous role with a small team, it was good to look back on the past two weeks & call out the things in a group setting that had gone well, or hear about wins that I wasn't directly involved in. Just created a great sense of forward momentum which I personally found really motivating. If some process wasn't working well for us (including the way we ran sprints) then the next retrospective would only be a couple of weeks away & we could discuss if it needed changing then. By the time I left it felt like we'd got a really well-oiled machine going. That kind of frequent communication and sense of shared forward momentum is one of the things I actually really miss now that I'm working solo again to be honest.

[kahnclusions]

In practice I usually see that when developers finish tasks early, then they don't just sit around doing nothing for the remaining 2-3 days, they pick up new tasks right away. This means there's never a clean "end" to the sprint, it basically just turns into Kanban with scrum ceremonies.

It's quite difficult to get an org comfortable with developers having so much downtime at the end of a sprint where they can spend those days focusing on other stuff.

[freedomben]

Do you actually get to take a break or a rest when finishing the sprint work early? In 10+ years of doing sprints, I don't think that's ever happened to me or my team. In practice if we finish early (which is rare, maybe 1 in 5 sprints) then we try to jam in some refactor or performance fix or bug fix or something, and that ends up taking at least the remaining sprint time. There is never a chance to catch a breath.

[jakevoytko]

Scrum (and similar processes) are usually better than the absence of process. Sure, occasionally you have lightning in a bottle and have 5 proactive self-organizing engineers that are pro coordinators and communicators, or you have a team with a tech lead that just magically makes everything run smoothly without anyone really noticing. But even teams with the best engineers often struggle with scheduling and communicating large projects to executives.

Scrum is a fine default for any software engineering team working on app/website-style engineering projects. But if their process never veers away from default Scrum, they're probably not a very good team. I've discovered that good teams are fearless about retros. They take suggestions seriously If they're unwilling to try new things, they're always going to underperform teams that experiment with process, and keep the good and reject the bad.

Scrum (and similar processes) makes every engineering team move at roughly the same speed. This is good news if you have a poor-to-medium quality team and is frustrating if your team would be speedy without the process. Teams that don't adapt the process to themselves and their companies are always gonna feel like they're stuck in the mud.

[QuiDortDine]

"Fine default" indeed, as the alternative for a Scrum-inspired process is often nothing. I expect a lot of people hating on it come from big corps, where bureaucracy is already stifling. In a startup, Scrum may be your best way to protect an inexperienced development team from unmeasurable stakeholder expectations.

[_jesse]

Nope, hate sprints. Continuous planning works much better in my experience because it is _actually_ agile. It lets you constantly reset what your current priorities are. It lets you plan out projects and think about the projects and what it's going to take to get them over the finish line, without the constraint of "well, what do we think will fit into the next two weeks"? Also, sprints totally strip autonomy from engineers, I don't know why anyone would argue that they give engineers more autonomy.

Honestly, I just really hate the arbitrary timebox and all the problems it brings. You totally don't need sprints to do anything that's a part of the scrum process. Want to be more introspective as a team? Schedule a meeting every few weeks to talk about problems you're facing as a team and how to solve them. Want to plan out your work in advance? Cool, do that for every project you're going to be tackling.

[lelanthran]

You're asking this question of a process literally named "an unsustainable burst of speed"?

Big-A-Agile is a mechanism of naked greed to a) Micromanage employees times down to the 15m interval, and b) Ensure that the company is getting no less than 8 full working hours from each engineer[1] ... and then getting the engineers themselves to police each other over this.

Big-A-Agile "sprints" are a way to get the entire team to slowly move to the working hours of the most psychotic workaholic in the team.

If you think any of the above isn't true, try estimating less aggressively, and watch how your team "corrects" you if you keep it up. Or see what happens if you consistently miss sprint task completions on those tasks that were "corrected".

[1] Although they never complain when your sprint is completed, with every task completed, even though you were off sick for one day. They know that this means you legally worked more than 8 hours/day.

[riffraff]

Nitpicking: planning should not take a lot of effort, it should boil down to "pick the top of the backlog up to estimated capacity".

So the problem you have is perhaps with grooming/estimations. Those have more value if the product owner is not part of the team, and if you work on new developments, as they help prioritize deliverables (we can do X with N effort or Y with 3N).

I personally like sprints as they provide checkpoints, but they should not be treated as deadlines.

It your workflow is just "do this then do that" with no feedback loop related to what you'll work on, then estimations are not useful and sprints are also less useful.

[overgard]

My experience is that they're not particularly useful. By trying to fit everything into two week windows, the team either overcommits and works harder than necessary for no true reason and risks looking bad, or they undercommit and things that could be done today get delayed until the next sprint.

That being said, my experience is that most teams start off being strict about sprint planning and boundaries, but over time back off more and more until sprints are a very abstract planning/check in every two weeks, which is fine.

Just personal experience, YMMV.

[q7xvh97o2pDhNrh]

The entire "Agile Manifesto" is less than 10 lines, and it's right here for free: https://agilemanifesto.org/

If you want the longer and more detailed treatment, that's right here too, and it fits in 1 screen: https://agilemanifesto.org/principles.html

That's the whole thing. All of the "sprint" and "scrum" stuff was invented as a way to pretend that software-engineering is like factory work. You'll hear these people talk about things like "holding engineers accountable" and "making estimates more accurate," which is an instant giveaway that they don't understand the fundamentally organic and ever-evolving nature of software-engineering.

The only thing that actually needs to be done is to write down clearly the business problem to be solved, the reason it matters, the proposed technical solution steps in order, and the rationale for the solution. Then, meet regularly to talk about it and update it based on reality.

But most companies can't handle that level of rigor in their business thinking — or the idea that engineers should have this kind of autonomy to solve business problems.

[ike2792]

I've spent most of my career in Infrastructure and I've found that sprints are a great way to keep a software team focused. A big temptation in infra is to take on a lot of things at once but move at a snail's pace on all of them. Even (and sometimes especially) very talented senior developers fall into this trap b/c in infra at a medium-large company customers are always screaming and everything is always "urgent." Sprints force defining tasks clearly enough to scope them and limit work in progress. Kanban can be effective at this also but any time I've been on a team that uses pure Kanban people always end up with 5+ tasks in progress for weeks.

The most important part of making it work is to have the team manage the process instead of some external scrum master, and to have frequent retros and adjust the process as needed.

[mike503]

SAFe is a cancer. It's marketed amazingly and gets the C levels all excited about metrics and other middle management sees burndown charts and other flashy things. But in my experience it's gamified, it's not a one-size-fits-all approach, 2 week sprints complete with all the ceremonies. Nothing ever happens from the retrospectives. Nothing happens if you're delivering more points than your capacity allows. Meanwhile you fear if you don't fill your capacity enough that means you're underutilized. "We don't track points for that reason" - famous last words.

Every company I work for has wound up starting out optimistic and trying to drink the koolaid to see it slowly go further away from the original plan, but they don't seem to actually break up with it.

[brainwipe]

I've done waterfall and agile over 20 years and have yet to see a SCRUM like system deliver for either the business or the developers.

Agile (regardless of SCRUM, Sprints, LEAN, KANBAN etc) only works where the whole project breathes it from business client to support. The contract can't be fixed term, fixed price and fixed scope and be agile. The closer you get the client to the project, the higher the chance of success because only they truly know where to cut scope or what minimum viable release looks like. There should be no surprises, fast loops ("I don't love that feature but I can wait until next release, it's good enough for now") and financial realism.

How you then organise yourselves doesn't really matter. Right now I'm at a company that's multi-tenant kanban, we release when the code is ready. That could be every 2 days, it might be once every 3 weeks. The product manager, who is very close the customers, decides when to push what's been coded out. It gets merged and then into the test/UAT pipe. Releases are cheap, test has a lots of regression automation. I describe it to management as a river. Keep the tickets flowing like water. Get rocks out the river, make it wider with more people or faster with better tech/stack/devops/etc.

Everywhere I've worked that has had a strict SCRUM ended up being micro-waterfall where devs might story point 1 sprint but the management would plan out the next 5 to get to a release date, story points were converted into estimates, which were converted into deadlines, guesses became promises and scope could never be cut. Developers end up burning out and that vital domain knowledge is lost (the worst companies think devs are interchangeable). It was almost worse than waterfall because with waterfall the project managers got the blame, with SCRUM, it's the devs that carry the can. As one colleague said after a ridiculous meeting where our story point estimate was being compared with another team on another project in another country "it's just a stick to beat developers with". And he was right.

You mileage might vary! My experience only.

[JohnBooty]

I have seen all of those things happen! They are real pitfalls!

But I truly do not follow your reasoning here. What you are describing here are truly odious management practices that violate just about every tenet of those methodologies.

This seems to be like blaming a recipe instead of a cook who willfully, knowingly contradicts the recipe at every possible moment.

Thoughts?

[Zigurd]

Calling them "sprints" comes close to directly contradicting the Agile principle about a sustainable pace and not burning out the team. I'm sure I not a true Scrum Scotsman about that. But Scrum jargon gets consumed by management above the project team and misinterpreted.

Start by calling iterative cycles, or even individual cycles of task completion if you are not all "sprinting" together, "iterations." Get rid of as much jargon as you can. Then everyone, inside and outside your Agile world will understand what you are talking about.

Ron Jeffries calls what you are getting at "Manifesto Agile" which label unfortunately never gathered much momentum, but it's a good idea.