Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Do Agile 'Sprints' Benefit Software Developers?
73 points by rickcarlino on July 21, 2023 | hide | past | favorite | 119 comments
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.



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!"


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.


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.


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.


I mean, you know this, but 3 or 6 weeks isn't going to help if your problem is unrealistic micromanagement.

The underlying management problem there is they're more concerned about hours worked than work completed.


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.


     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.


^^^ 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.


    Agile, with its warts and all, is far better than nothing at all.
Yeah. You see criticism of agile, all of which is generally totally valid, but I never see alternatives mentioned short of "have a team of top X% developers with a clear shared understanding of all objectives and essentially no interference from management and no unreasonable deadlines."

Which, well... I mean, great if you can get yourself into a situation like that. That sure is better than agile. It is the ideal I yearn for as an engineer.

I just don't think that's realistic for most engineering endeavors. At some point, engineers need to recognize that interfacing with the rest of the company (product owners, etc) is a big part of the job and really embrace it. It's also typically the only part of our job that is not easily outsourceable, so it is in our best interest to embrace this.


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.


> 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.


The urgency is often fake. You complete your sprint, only to find out you built a feature nobody needed any time soon (or maybe ever.)


This is my biggest beef with deadlines in general and sprints in particular. The urgency is fake, but the cost is not.

It is not 'free' to set a random deadline. You will pay with productivity and quality and cause stress. There is no way around it, so do it for a sound reason.

These days if somebody sets a deadline I always probe them to find out why. "What happens if we are a week late, a month? Is there a reason for that date?" This often annoys people, which reveals me they don't really know what they are doing and it is not actually a real deadline. Just something that people think that project management is.

99% percent of deadlines could be replaced with something like: "this feature is worth a ballpark of 2 to 5 weeks of the team to me. Can we make it? Keep me posted if it doesn't work out, I want to know so I can consider dropping it and pivoting to something else, even when we already invested 4 weeks in it."

That is a reasonably thing a manager can ask, and more often than not developers can actually answer this in a much more efficient way than detailing and monitoring a sprint plan.


I built something in one sprint, only to see it replaced with "V2" two sprints later. "V1" was never used by an actual end user. But, yeah, it worked for demos!


> 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?


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?"


Because sometimes you stumble on a graveyard and you end up cleaning out the corpses of developers past.


Beautifully put.


This is only a guideline, don’t treat it like a hard rule. There could easily be good reasons why a 2 point story took three weeks.

Also gotta stop the negative bias. People will want to complain easily if your 2 point story takes you three weeks, but no one will be singing praises if your 5 or 8 point story is done in a day.


    There could easily be good reasons why a 2 point story took three weeks.
If it was because you were interrupted and given other priorities, that is totally valid.

If it was an estimation failure, that really needs to be looked at and learned from.

I find that this is typically a problem with management and/or process, not the engineer. We as an industry typically do not respect the time it takes for engineers to produce an accurate estimate. This time itself needs to be treated as a first-class concept and time needs to be allocated to it which, in practical terms, often means it needs its own task/card/story/ticket/whatever in the framework of one's choice.

There are nearly always unknowns (typically some kind of externality or legacy code) to explore before we really know how much time something will take.


If you finish your 8 point story in a day, you should pace your work better. ;)


Not necessarily. It could take longer because the original estimate was based on incomplete or invalid assumptions.


My assumption was that if you're not performing sprints, you're not assigning points to stories either.

I don't know why I made that assumption.


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.


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.


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?


Mostly because it wastes time (and money, for the company.)


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.


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.


Lol, honestly how fucking stupid. Here you have managers failing to understand the most fundamental basic part of their job.


> 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.


> 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.


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

Only half joking!


The issue is that agile was once (back in the days of the manifesto) a grass roots effort to make life for developers better, but in many companies it has been perverted and twisted from a framework for collaboration and self-organization to controlling and pressuring development teams in a fortnight cycle. Of course this gives Scrum a bad rep.

May an on-site therapist help more than just replacing attrition? If it would (in terms of net profits), many companies would have started to do so.


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!"


There are so many reasons sprint goals are abused, it can be it bad management culture trickling down, people in charge not understanding even the simplest points of the Agile Manifesto, or even weird companywide KPIs linked to Scrum or Kanban completion metrics that you can so easily pull out of most agile management software (e.g. Jira).


Our scrum lord told us his bonus is tied to these metrics so you can guess why managers and scrum lords behave the way they do in spite of the manifesto. Throw the manifesto out the window its complete bullshit because they say one thing and do another.


Indeed, Scrum looks nice in theory, and can be nice in practice (from my personal experience), because in theory it is about self-organizing of teams and collaboration with the product owner.

In practice however in so many companies it is totally twisted and used as a method of control, and applying pressure, as you said by e.g. making metrics bonus relevant.


"scrum lord"

lol.

Scrum is great when it's run by and for the dev team. As soon as it's co-opted by management as an easy way to 'inspect' performance, as a developer confessional/inquisition, etc, it becomes a living nightmare.


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.


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.


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.


How will this approach work with larger teams?


That's a good point, the alignment approach doesn't scale as the team grows from dozens to thousands.

But the fundamental question isn't "how can we support ever larger teams" but "how can we create better software"? I don't see any evidence that "larger teams" produce fundamentally better outcomes.


I can align with that, given my own experience. Going back to your original point, of alignment, how does that work in practice, with a diverse team of different expertise and experience level?


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.


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!


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.


    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.


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.


> 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.


Those types of conversations are going to depend a lot on their context.

Like, if your company is a large company that has a lot of operationalized tooling around corporate agile, one team saying "hey lets not do this" is not going to go over super well. A smaller company with fewer and/or more autonomous by culture teams will have more success.

But it will also depend on what kind of way its communicated. Can't just say "lets stop doing sprints", you have to make sure you're justifying it and/or offering alternatives that speak to the needs of the other members of your team/company.


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.


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.


> 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?"

I think this is the most common way that the concept is abused, and it's very, very easy to fall into this trap. I suspect that it comes from an idea that the sprint length is sacrosanct so having tasks that go beyond a single sprint is to be avoided. Sprints should be a planning tool, not a hardcore thing.


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.


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.


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.


No -- that's not quite what I meant -- more of a "logical break" in the work. A chance to come up to the surface and gasp a moment before diving back in for more on the same project or set of tasks because there was a clear breakpoint.


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.


"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.


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.


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.


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.


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.


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.


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.


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.


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.


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?


You're quite right that the recipe is abused by a cook. I like that analogy!

However, I think a vanishingly small number of corporations care enough about the recipe to cook it properly. The recipe itself can be abused. A better recipe would be safe from abuse.

I'm not sure what that recipe looks like.


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.


Agile/scrum/sprints are the garbage dumpster on product development introduced to wrestle back control from SW developers. Unfortunately, nowadays, the majority folk know nothing else than this and all the buzzwords associated with this garbage process. Those who worked with different models talk it down and make a mockery of it. Ultimately it was introduced to track webpage developers but has been adopted anywhere the word software is used. It's death can't come quick enough.


Let's just get clear, I'm firmly against the cargo-cult version of scrum and sprints that looooots of companies and teams are applying.

To get back to your initial question about how you reconcile sprints, and more largely scrum, with the agile principles, it's actually pretty easy to do if you take a bare scrum and the principles themselves*

1. And 4. Customers are more satisfied and involved when you ask for guidance and feedback, i.e every two weeks when they look at what you did and tell you what is next

2. Welcome changing requirements - when you lock scope every two weeks, instead of at the beginning phase of a 6 month waterfall plan, this is checked.

3. 7. Continuous delivery - sprints are supposed to finish with a new version of the software that offers more features.

6. Face to face interaction through including business into demos and planning at leasing every two weeks.

And so on.

But.

The *moment* you depart from initial intent, it all goes through the window.

You commit to delivering a feature 6 months from now - you're done.

You stop delivering working software every two weeks, you're done.

Management starts interfering with roadmap, architecture, estimates and work method, you're done.

You insert pms and pos and layers and layers between the dev team and customers, you're done.

Etc. And of course scrum has been received by a layer of people who were used to working with a certain degree of control and certainty and tried to bring that back in scrum, which ended up making it worse than waterfall on all aspects (except maybe PR because no-one wants to sign up for waterfall).

Instead of taking a step back, thinking about what they need, and picking tools and practices that serve them, teams end up taking the thing as a whole, setup all the planning and grooming and demos and retros and blindly without a glance back, forgetting to apply any ci.

Can you reconcile agile and scrum? Yes. Should you "do scrum", fuck no.

* http://agilemanifesto.org/principles.html


"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?"

The fact that deployments happen multiple times a day is not exclusive of the fact that multiple deployments can fit inside one sprint.

I'm not a fan of Agile. But I don't mind the idea of "Let's define things we can get done in the next 2 weeks. And see what we can get done by the 2 week deadline, then reflect on it."

I think there needs to be a defined timeframe (of estimated time-boxed phases or whatever you want to call them), in order to reflect and measure outcomes.

In life, in some cases, meeting a requirement by a specific deadline is extremely important because the consequences are potentially very expensive.

For example, if you're organizing an in-person event of dozens, hundreds, or thousands of people. Clearly, your team must have produced the promised outcome by the deadline, resulting in as perfectly smooth an outcome as possible. Otherwise there is massive chaos, embarrassment, financial expense, and even legal consequences. The same consequences are present in even small & medium sized professional software companies.

Whereas, in software, if you're on a less important Proof of Concept consulting project... it might be OK to deliver 2 or even 4 weeks late-- there can be more flexibility, due to various factors.

The time period's name, its amount of time, its amount of work achieved... that's all fungible and flexible.

But to say "I got these 3 things done" vs. "...in 1 year" vs "...in 3 months" ...these are important details in the context of most peoples' work-- because time is a resource and a metric.

I really don't mind sprints. What I dislike is:

- Daily Standups that occur more than 3 days a week and last longer than 10 minutes. It's nice to see everyone occasionally. Forcing me to is a pain. For those other 2 days, I'd rather silently sit in on the Managers, Directors, and Architects' Daily standup (That said, if it's not genuine it could turn into a staged performance for the peons).

- Managers without Software Engineering experience leading standups

- Non-engineers not being required to give their Daily Standup report. Team Managers, Project Managers, others -- If I have to give a report, you should have to give a report as well. We should all feel the same pressure to be on point.


Scrum is a method to allow agile development to sort-of work within a management structure that needs waterfall. It provides observability of work getting done by developers, without as much up-front external design as waterfall. It's not intended to make developer's lives easier, it's entirely for management's benefit. It reduces the ability to respond to change, but in return provides management with easier scheduling.

That extra scheduling is sometimes not important, but often it is. If you have external vendors or contractors they'll have their own schedules; your company will be paying them for their time whether you can keep them working or not. Predictable delivery can be very important. E.g. if you're making a hardware device, you'll have a "slot" in a factory schedule. If your firmware is late, you're still usually paying for that time slot (the factory employees still get paid), and you're paying extra to get another time slot (as well as for any downstream delays).


So, for some adversarial reading, I recommend taking a look at: https://basecamp.com/shapeup (The digital copy is free) I'm 100% sure that the CTO is a megalomaniac and that the actual author of the book was fired for idiotic comments...but the book has some pretty wild alternative ideas of how you can plan and accomplish work that are focused on delivering work rather than charts for CTOs. The book does make some base assumptions though: 1. You have good workers who think independently. 2. Your org allows you to have task-based teams, that is: Teams made up of a designer, an accomplisher, and a manager. 3. It works better when work can be done without external factors impeding it. 4. Your leadership takes the time to set the vision in stone and agrees to it. (This is generally the biggest issue with sprinting: You are allowed to change direction too rapidly so larger projects rarely get accomplished on time as priorities flip-flop.)


At one company, we did do sprints, including retro and burn rates and all that, and none of the devs liked it. Bloody story point poker was a biweekly low-point. Where I am now, we work with a mid-to-long term goal, split up in limited tasks and sub-tasks to reach that goal, testing task by task, and deploying whenever it's ready. That works much better for me. But it's a small team, so that may help.

> Interruptions and unforeseen tasks will occur.

That's certainly the case in my current job. Since the product is used for commercial projects, bugs and smaller problems crop up and need to be addressed, usually with priority. And my colleagues regularly need support because they messed something up. It takes a lot of time to make a product fool-proof, and it's nearly impossible to plan.

So I'm in favor of incremental tasks in a larger design. Setting artificial goals and deadlines, which often won't be met, is only a source of frustration, not progress. But getting a larger design done in this way really requires that one person has the oversight.


I like some aspects of it, mostly the ability to say, when someone asks for something to be done Right Now, "here are the things I'm committed to for the next two weeks. Which of them should I not do to make room for this new priority?"

I do NOT like the idea of a hard beginning/end of sprint, it's a pipeline stall.

I generally like to have something I'm planning, something I'm working on, and something I'm working through review on. If I have to be 100% delivered at the end of the sprint that means I have to budget to be finished with all work and just be sitting around herding PRs the last 2-3 working days.

We don't do sprint planning until the first day of the new sprint so I can't really start speculatively executing on next sprint. So I usually overcommit a bit just so I will have stuff in progress at the end of the sprint, and then just eat the PM stinkeye when we don't burn it all down.


    "here are the things I'm committed to for the next 
    two weeks. Which of them should I not do to make 
    room for this new priority?"
Yeah. People will scoff at this and say that you don't need agile or sprints for this. And they're correct, but naive.

Certainly I have successfully done this in the past without fancy agile religion or ceremony. In fact it's a valuable skill for any job in any industry.

But it has always been hard to do and I'm sorry, but most people (both engineers and managers) are bad at it most of the time. The industry clearly needs help with this concept.


Strict WIP limits do not address the fundamental problem sprints attack: that of strategic execution flexibility. This need for flexibility is driven from higher above the developer, at the strategic (business model) level. Done poorly, sprinting usually devolves into micro-water fall. I think this is simply because that is what project and product management knows. Done well, sprinting does aid at the developer level. They are focused on a task and completion gives them a sense of accomplishment.

Sprints are a huge disruption to the established order of project and product execution. They are an artificial time block competing against real world priorities. Companies that do agile sprint execution well have created an environment where planning above the developers is in sync with "time boxed development". Achieving that varies widely. This, in my opinion, is an area ripe for innovative thinking.


I'm the author of the first book on Sprint Goals (Driving Value with Sprint Goals: Humble Plans, Exceptional Results). I'm not working in game development. However, I do think I can add some insights.

Sprint Planning can be very simple. I've literally started a Sprint with just a goal and a Spike. You can also work entirely pull-based (https://mdalmijn.com/p/are-you-practicing-anaconda-or-hummin...).

The Sprint is supposed to be wholly flexible. The way I describe it, it should be like a pendulum that swings by and you check the progress you've made. That's it.

Yes, it's all achievable without Sprints. The biggest difference is that the Sprint provides intent: what are we trying to achieve, and why does it matter? You could also do that with Kanban together with a goal. If you can't or don't want to set a single objective for two weeks, then you should do Kanban and not Scrum.

"Most benefits attributed to sprints could be addressed through strict WIP limits." -> No. The only difference is that you set an objective. You can use WIP limits and Sprints together.

" 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." -> Most developers don't like Sprints because they turn into a push-based batch process, where the goal is to complete all tickets in a Sprint. This usually means you actually complete less work than when you'd use Kanban.

The key to make Sprints work: * Use pull-based approach compatible with WIP limits. As I call it, Hummingbird-style Scrum. * Set a single Sprint Goal. When your estimates turn out to be wrong, which they always will, you know what matters most and you can apply focus on the primary objective.

That's it.


No. There is no benefit. None.

If a team decides to split up work into certain chunks in order to get something out the door than that is up to the team in that specific time and that specific place.

This lunacy of copy/pasting whatever worked for one group in one life and applying it to another in another life baffles me.

Get humans. After they learn to trust each other and learn how the operate together you will have a unique mix. Unique. One of a kind. Have that unique entity decide how they want to deliver value.

As soon as the unique entity changes because humans leave or join, redo from start. All bets are off.

And a manager or company should focus only on how they want progress to be reported. Progress time and rapport format.

Expecting sprints when being a a manager or executive is dumb and immature.


Sprints need not be anything more than “what did you get done this week?” It’s useful to feel progress. It’s useful to notice when things turn out to be more complex than we thought (dragging the same task from sprint to sprint). It’s useful to notice when unplanned work crowds out planned work.

I don’t think it’s useful to have a very rigorous planning process, or be persnickety about things finishing within the sprint vs. 2-3 days carryover. I particularly hate the rituals designed to reduce autonomy, like PMs managing backlog priority or story points poker exercises. On my team engineers are responsible for their projects and the sprints are just periodic check-ins where you say what you have been doing and what’s next.


Sprints do give faster feedback, early value and autonomy, but only in contrast with planning the complete project upfront in utter detail and committing to a deadline. It's a compromise. Instead of planning a whole project we just do two weeks and go from there.

Its a nice idea but it often doesn't pan out in practice. The sprint is way too detailed, the team gives too much time and attention to planning the next two weeks and too little to what comes after, often people don't really know what to do when they finish early or don't make the sprint, etc. But most of all, everything becomes this game of predicting the sprint and finishing it rather than solving the most important business problems right now. It becomes a bureaucratic thing (in a bad sense).

For me, two weeks is usually too small of a timeframe to get something really meaningful done, so the sprint goals feels like a collection of random things we stuffed in two weeks. Most people also adhere religiously to the goal of 'achieving the sprint', which pushes the team to planning together in way too much detail. Not achieving the sprint feels like failure and you will get 'punished' if only by disapproval. We should take it as feedback and rejoice in the opportunity to hone our estimation skills, but in reality it functions as a reverse gamification mechanism making devs conservative and risk avoidant.

In an ideal situation, what sprints give you is control over delivery schedules. But this control always comes with a price, and two weeks into the future isn't far enough by far. It's never free to set a hard deadline. So you pay with lower productivity in order to get higher control over schedule.

I think its better to set looser goals, have a course roadmap of things you will be working on, problems you want to solve, but don't fret over 'velocity' and 'story points', just like you are not counting lines of code produced per day. Story points are meaningless, what matters is if you have solved some problem. That is what gives you autonomy, value and feedback, not 'achieving the sprint'. Nobody cares about that.


> 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.

These both ring very true in my ear based on 3 years of agile dev at FAANG, less so from the 1 year at a startup. Neither were issues at the other FAANG company I’ve worked for, where devs were given more independence and trusted to deliver when they could.

I think sprints are a useful tool when you’re trying to hit tight deadlines with a group of devs working in parallel. However, I’m not a fan in general.


Now this may be a bias that comes from running on a track team, but I've always been annoyed when my team ends one "sprint" on a Wednesday at noon and starts the next "sprint" at 12:01. We're "sprinting" non-stop. They really should call them "marathons" or something that more accurately captures what the bosses want.

I believe the original idea was that there would be plenty of downtime where the team would study the problem and think about the best way to attack it. Then when there was a solid plan, the team would sprint to execute it before returning to thinking carefully about the next issue.


In my experience, a continuous stream of frequent iterations is very effective, but the driver for the early iterations must be "eliminate risk", not "deliver value". Sources of risk include novel functionality, the architecture's ability to support the functional and non-functional requirements, dependencies on external teams/tools/services, and politics.

Focusing on value delivery before the big risks are eliminated often results in facing a nasty decision: rip up a lot of already-laid track, or live with a sub-optimal organization and/or project structure.


I find sprints to be just a useful tool in the toolbox. It helps you plan, but you also need to be careful that it doesn’t consume your team.

But ultimately what matters is if your team can recognize what works and what doesn’t and be able to think of a solution. You end up with your own custom hybrid solution.

You know how there’s people who don’t really understand code and just copy from Stack Overflow? Well, learning about agile (or any methodology) and directly implementing it as-is is the equivalent for a planner. All they can do is repeat what someone else figured out without any understanding about planning.


I think it's very useful to break work planning up into discrete stretches of time. This isn't something that was new with agile, either. It's long been a thing.

I think breaking work time up into finite stretches of time and having a reassessment in between them benefits everyone, including devs.

I think it's very easy to go overboard with the concept, and it's very easy for the concept to be abused, but that doesn't take away from its basic usefulness. I also don't like that they're called "sprints", but that's just a nomenclature issue.


Breaking up work in manageable chunks absolutely makes sense. It makes it easier to monitor progress as a manager, and gives a sense of achievement for a developer.

However, the rest of Agile deserves a special circle in hell.


> Breaking up work in manageable chunks absolutely makes sense.

But this isn't unique to agile. it's basically how all objectives since the 50's have been organised.


Yes, agreed. It has just been given a special name (sprint planning) to justify the cost of Agile consultants.


Sprints are effective for delegation. It is a way to communicate what to work on, the order and how long tasks are expected to take. If a tool like JIRA is used more systematically, we can just document and communicate many things thru it.

Plus we get a statistical sense of progress after a few sprints. Some people prefer visuals like Gantt charts.

It is best to encourage individuals to plan their tasks in a tool. Some tool is critical to a sprint, it is a way to get some writing reps also. Others can read and provide feedback. Post-its on walls is not effective sprint planning.


I enjoy the smallest investment in our sprints we can manage. If done well, it keeps outside interested parties informed while keeping a realistic sense on what I plan to achieve

My problems with it start around the time when I'm being impeded from the actual work. Justifying the hurdles I've anticipated or bike-shedding on the cover sheets


> Interruptions and unforeseen tasks will occur.

In a highly interrupted team, sprints don't work. Try lean/Kanban.

You've not mentioned retrospectives, which are an important part of improving your processes, without that how can you make improvements?

There's nothing in agile that talks about deadlines, it's about commitment.


It's a misconception that Sprints don't work when you're highly interrupted. Sprints are as flexible as Kanban, with the only exception that you set a single objective per Sprint. This is the thing that matters most.

If you can't set a single objective per Sprint, then Sprints don't work. Any flexibility argument reflects a poor understanding of Sprints.

Here you can read more: https://mdalmijn.com/p/are-you-practicing-anaconda-or-hummin...


> commitment

I am convinced that when people talk about burnout from trying to hit sprint goals, it's because of this word, and either being coerced one way or another into commitments they can't meet, or not having enough information or experience to judge what a reasonable commitment is.

It was recently changed in the Scrum Guide from "forecast", which is much more reasonable: you can track forecasts over time to improve them, and nobody expects a forecast to be bang on the money every time. "Commitment" doesn't work that way.


'Sprints' work well if the team has control over what they do and what sprints look like. Normally that isn't the case. Business end up expecting work to be done in X amount of sprints which makes no sense. Architecture is forgotten.


Yeah, a sprint is an artificial deadline, which is just wrong, IMHO.

That said a 1 or 2 week deadline is much better than the 6 or 12 month deadlines you easily get otherwise. If management needs to have deadlines, shorter ones are less damaging.


No. Agile is for companies to keep track of the work their developers do. It's just that simple. The problem is non-technical people trying to keep track of what technical people do is bound to fail and cause friction.


CI/CD only helps release often if you're only producing one component. If you're changing multiple different components then you need to sync them all up so that they're all releasable at the same time. A sprint gives you a deadline for everything being releasable again.

WIP limits are great until you're waiting for more information from a supplier on one ticket, feedback from a customer on another, and help from an expert from another team on a third ticket, so you sigh and pick up a fourth ticket so you're getting something done.

Artificial deadlines aren't great - but you can always extend a sprint if the team needs it. And preferably your tickets shouldn't be a whole sprint long anyway, you should be getting multiple small things done in that time.


> If you're changing multiple different components then you need to sync them all up so that they're all releasable at the same time

You don't need to sync them all up at all. In the majority of cases it's feasible to release multiple changed components one by one. Doing so results in better outcomes than trying to aim for big bang releases.

> WIP limits are great until you're waiting for more information from a supplier on one ticket, feedback from a customer on another, and help from an expert from another team on a third ticket, so you sigh and pick up a fourth ticket so you're getting something done.

This is a failure of management, not a failure of WIP limits. The correct thing to do in that situation (at least, from the point of view of WIP management) is to down tools and escalate, not to bring more work in.


Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to down tools and not do any work until they do?

I do not think I want to work with people like that. Things can not always be done instantly to fit the whims of developers. The customer may need to get together a few people and discuss what they want, which may take a few days to schedule. People may be doing other important things and not instantly free to drop everything to get you what you need. You may need to realise that you are not the center of the universe.


> Your response to realising that you need some more information from someone part-way through build, and they won't be able to get back to you instantly, is to down tools and not do any work until they do?

It depends on context, but I won't write it off.

Here's the thing: it's correct from the point of view of managing work in progress. If you value responsiveness over busyness and presenteeism, you absolutely do not want to risk your utilisation approaching 100%.

If you actually don't care about WIP, sure, pick up the work.

> Things can not always be done instantly to fit the whims of developers.

It's nothing to do with the whims of developers, and I'm not sure why you think it's reasonable to write it off like that. If I'm in a system that's managing WIP, there's a reason for that. WIP-management is frequently used to keep the lead time for any given work item as low as possible; if I'm blocked on three things that means lead time on all of them is out of control and that's absolutely a management concern. Or mine, if there's anything I can do to get them unblocked. Picking up additional work while they're blocked means I'm guaranteed to be busy when they come back in, making their lead time worse than it would have been otherwise. In that situation it's exactly the wrong thing to do.

> I do not think I want to work with people like that.

That's fine - one "You may need to realise that you are not the center of the universe" and I don't want to work with you either.


I like the idea of sprints as a simple “here’s my goal this week” sort of thing. Much more structure than that and it feels oppressive, less than that and it feels amorphous beyond the goals of a day.


I have seen the demo to be empowering for the team towards the company. It would be a waste to let all the developments just silently CICD into production.


> Do sprints benefit developers?

No, "agile sprints" are meant for pacing developers.

  - Issue tracking helps developers keep track
  - Kanban helps developers keep focus
  - Planning two weeks ahead helps developers keep priority
There is something fundamentally unhealthy about sprinting for 2 weeks, again and again.

When "agile sprints" work well, they're either ultra-marathons (an acquired taste) or jogs.


No, they give management predictive approaches to estimation and that's what their purpose is.


Hi! I was involved in the Agile movement before the term existed. I came up through the "Extreme Programming (XP)" school of thought, and later on the "Lean" one (in the Poppendieck sense of the term). Here's my take.

The "sprint" is an artifact of the transition away from waterfall. Getting people to go from an 18-month planning cycle to a 30-day planning cycle was an actual advance. But as you are seeing, it has its problems.

If you keep turning up the dials, as the XP folks tend to do, you get to weekly cycles. Those are about the smallest effective "sprints". I like them a lot better than monthly sprints, which are much more likely to be mini-waterfall in orientation.

At a weekly cadence, you can start to see what might be beyond that. For me that generally involves a weekly meeting schedule, but otherwise a Kanban-ish flow of work with strong WIP limits and aggressive effort to keep work unit size to be well under a week.

So yes, I think you're correct that continuous delivery (which was invented well later than the original Agile methods) means that sprints no longer have a release-related reason for existing, especially when you have a good feature flag practice.

In practice, I think humans do need some regular rituals and that some planning work is better off batched, so I'm ok with keeping some sprint-like rituals, like a weekly planning meeting and a weekly retro. But I think high-functioning teams treat those as convenient sync points with flexible adaptation of plans as new learning happens over the course of the week.

And yes, I think the Agile community broadly got stuck in a mini-waterfall space rather than what I think of as actual agility, so your read there is correct too. I think the main driver of this is managerialist ideology [1], which centers managers as the vital actors in business. In contrast, flow-based processes like you describe make managers mostly irrelevant. Unfortunately for those of us who like to actually get things done, managerialism is the dominant ideology in American business, so much so that its tenets are not only mostly unspoken, but that alternatives can be unthinkable to many. So I expect things like "scrummerfall" and SAFe to continue to dominate large-company software development for the forseeable future.

[1] See https://en.wikipedia.org/wiki/Managerialism and https://www.amazon.com/Confronting-Managerialism-Business-Ec...


This rings true to me. The way scrum works in practice is a, forgive my language, perverse inversion where the process has become the goal and the outcomes are less important.

I worked with 4 weeks, 2 weeks and 1 weeks sprints, and with 'just kanban' as well. I now work with Shape-Up, where the build cycle is 4 to 6 weeks, but rather than having a backlog we just have a defined (and designed) problem solution and get to create user stories (or whatever) when we need it and often fill in a significant amount of detail as we start tackling the problem space.

We started working in pairs, sometimes but not always pair programming, so most of the planning work is just with your buddy and fairly ad-hoc, it doesn't cost the whole team. This works pretty well.

But a good team will invent an ad-hoc 'process' on the fly as is required to solve problems, without descending into chaos.


> But a good team will invent an ad-hoc 'process' on the fly as is required to solve problems, without descending into chaos.

This is the heart of agile, but rarely gets implemented, in part because the Agile advocacy was not largely directed at the people who make the decisions that make implementation possible, but at people who lack that power.


For sure. XP looked at first glance to be heavily prescriptive. But the initial set of practices were always meant as a starting point for a team. The notion was to give them a safe context in which to experiment and adapt.

That was never really compatible with large companies, where managers need to feel in control and appear actively responsible for success. It also wasn't compatible with a top-down desire for "legibility". So in practice we end up with uniform process that's a bad fit for individual breeds


Agile sprints can help the team navigate changes fast. But the whole world of tracking, ceremonies and even performance reviews on it is utter BS. It takes the focus away from the actual goal of accomplishing things.


Of course not. It’s a jobs program for middle managers.


The benefit to the developer is that they're a delivery cadence agreed with people outside the team so you don't have to deal with constant "are we there yet" and context switching. Think of the sprint as a tool in the toolbox for managing up/out.

You have to think of Scrum as a self-defence: without something like it, the failure mode is the death-march.

> Overcomplication, with an entire industry of trainers, books, and seminars evolving around it.

That's inevitable with anything successful, though. It doesn't have to be complicated: https://scrumguides.org/scrum-guide.html should be all you need.

> Over time, sprint discipline often deteriorates or transforms into something less Agile.

That's a different problem.

> Lack of relevance for teams practicing CI/CD

This strongly depends on what your definition of done is. I've seen teams who think they're doing CI/CD who just plough features into a "next release" branch that only actually goes out to production once a month, or less. This goes exactly as well as you would expect.

But even in a continuous delivery world, I can still see value in "let's see if we can get X done in the next two weeks" where X takes several deliveries to get out of the door. Theming the work helps reduce context switching within the team.

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

If that's happening, it's not the fault of the sprint. The work scheduled into a sprint shouldn't exceed what's actually achievable by the team, without overtime or burnout. If people are regularly and repeatedly burning the midnight oil to hit sprint goals, that's a strong signal that there's something wrong elsewhere in the organisation that needs fixing.

> Inability to handle reality. Interruptions and unforeseen tasks will occur.

That's a weakness, but not fatal. Sprint planning should allow for enough flex to cover some unexpected work. You're right that WIP limits could handle it, but with a sprint at least in theory the idea would be that when something that bad comes up, it forces a conversation with the product owner to scrap the sprint and start a new one. The danger in only handling it with WIP limits is that that conversation might not happen.

I do think the current Scrum Guide has made a major error in characterising the Sprint Goal as a "commitment". For several years it was a "forecast" which I think was far more honest and less likely to prompt abuse.


I find it works well in two situations:

1. Protecting a software team in a non-software organization. In this situation the team has no voice in prioritizing work, is under constant pressure to deliver, and is generally viewed as a cost-centre by leadership.

Taking a lead role and introducing an agile/scrum-like process is a way to deflect unreasonable demands off of the team. The goal is to convince leadership that deadlines aren't as important as progress. Demonstrating regular progress and having check-ins is a way to console the existing leadership and build trust with them while the team gets breathing room to address their concerns and learn to prioritize what needs doing with what users want to be done.

Don't get too invested in it. The incumbent leadership might try to wrest control of the process back from the development team. If they get involved you'll notice more meetings, new job roles, and presentations with charts and diagrams explaining how the scrum/agile process works. This is plain old Taylorist micro-management sneaking its way back in. Be prepared to give up on agile/scrum before it gets to this point or make sure that your team is in control of the process and not external stakeholders.

2. Establishing a new team with customers in the absence of management. In this situation the customer is basically your manager. And they will want deadlines because money. Similar to the first situation, agile/scrum here is about managing expectations and getting parties on two sides with different priorities to work together and trust one another. If you can build up that trust you can ease off on the agile/scrum stuff as needed.

In every case the important part is that the development team, the people writing the software, are in control of prioritizing what work gets done and how it gets done. As soon as you have diagrams and presentations and several layers of "managers" involved in directing a software team you've entered into the Agile Industrial Complex and have dropped the ball.

Caveats: you will find that some developers will refuse to work with customers. They do not want to co-operate with management. They only want to write code and view any process to manage work as a waste of time. The important thing to remind them of is that you don't need to use any of the scrum/kanban/whatever processes forever. The goal is to get management off your backs by showing them your team can deliver results by shipping stuff on a regular cadence. Once things get into place you can change the process to whatever works for your team as needed. That's the whole point of being "agile." No need to cargo-cult rituals for the sake of performing work. Do it until you get the trust you need to get back to work.


Well, to decide whether "sprints" are a good thing or not, you have to consider the history, which is mostly centered around the alternatives.

"In the Beginning, there was Waterfall" -- prior to the era of agile practices, waterfall was king: first, gather requirements, then, design a system based upon those, then implement that system, then test it, then deploy it, then maintain it. And write volumes and volumes of detailed documentation about all of these steps.

While there is nothing really wrong with waterfall per se, it tended to annoy people greatly, due to delivering irrelevant software and tons of irrelevant paperwork in many (if not most) situations. Because unless you're, like, building a moon landing guidance system, "the business" tends to change too much between the requirements and deployment phases. And/or: the "requirements" people were simply not very good at their jobs. In any case, pretty much everyone was unhappy with the end results.

So, at some point, there was the "agile manifesto" movement, which tried to fix this from the side of both the "business" (which felt it was spending too much money all the time) and the "developers" (which felt they were doing pointless work all the time). The four main points of the movement were and remain:

(1) Individuals and interactions over processes and tools (2) Working software over comprehensive documentation (3) Customer collaboration over contract negotiation (4) Responding to change over following a plan

So, right away, most of your reservations about "sprints" seem to be negated by principle #1: Trainers, books, seminars and rigid CI/CD are not prescribed by capital-A-Agile at all. It's about you, your team, and what you decide to do. Of course, this may very well mean you should look for a different team, but that can happen due to many, may other reasons.

"Artificial deadlines" are, in my experience, mostly a commercial issue. A "sprint" is always a fixed amount of time, to be spent on development. If malfunctions and associated maintenance take time away from a "sprint", that should be covered by a support/maintenance agreement. If the same people work on both development and maintenance, the former should be paused while the latter takes place. So, a 2-week "sprint" may very well take 3 or 4 weeks, if interruptions take place.

This takes some adjustments in contracts, sales, etc. But I can assure you, that a "2 week sprint of uninterrupted development time" coupled with a "maintenance agreement that extends any development sprint by the time required for personnel to fix and re-focus" works quite well. Sure, some sprints will end up taking many weeks but that's all time that's paid for, and nobody will object to payment in the end, provided all is agreed upon in advance and backed by time-sheets afterwards.


Me: 5-6 years doing Scrum (more or less) at 3 companies. 25 total years doing software dev.

First:

    Agile
"Agile" has no meaning on its own to me. Typically an ad-hoc free for all with a Kanban style board in my experience. It's a way for companies with no process to feel like they have a process. I'm not saying this is wrong but since the term is so amorphous I feel it is impossible to discuss.

To me Scrum is a specific flavor of "agile" with some specific ceremony and convention. I will be talking about Scrum below unless otherwise noted.

TL;DR -- I think one's opinions of Scrum largely depend on how good or bad one's experiences outside of Scrum are. If you have been on amazing and healthy teams, then Scrum surely seems like a bunch of unnecessary bullshit. Sadly I'm not in that boat, so I have found Scrum to be a net gain.

    Overcomplication, with an entire industry of 
    trainers, books, and seminars evolving around it

    [...] sprint planning seems overly complex
For most engineering efforts, we're going to need some meetings, planning, review, and collaboration no matter what -- right? At some point we have to herd the cats.

My experience is that Scrum does not represent an increase in ceremony/meetings relative to the somewhat chaotic and meeting-filled reality I have experienced outside of Scrum.

I don't think that Scrum is perfect, but I appreciate that it is a somewhat standardized process. It's like MVC or Git or 90% of the other shit we use. It's not perfect but there is value in a standard thing that is more or less understood by everybody in the industry.

    Autonomy. I'm not sold on this either.
I find Scrum almost entirely orthogonal to developer autonomy.

I have generally found that management/product rams shit down developers' throats no matter what. Scrum doesn't help here but I don't find that it hurts.

One small exception: if management has bought into these concepts, story points + sprint velocity do provide a somewhat objective or quantitative way to measure developer work. Again, I'm comparing this to the alternative, which is "the industry has never figured out a way to measure this." If management has bought into the concept, it can provide a way to push back against their demands when it comes to deadlines and scheduling work. Thus, some small boon to autonomy.

    we want a drama-free, predictable, and coordinated 
    work environment where we're respected
Well, Scrum adds to the predictability for sure IMO.

The other attributes... well, they have not typically existed in this industry anyway IME.

    If so, why and how do you make [sprints] work?
A common failure in agile/Scrum/sprints whatever is pressuring developers to estimate work (story points, whatever) before they have had a chance to really explore what needs to be done. For example, adding a feature to some legacy code the developer isn't familiar with... will it be easy or hard? No way to know until they've done some spelunking and maybe even an initial POC.

It's actually a fundamental concept in Scrum and I guess "agile" in general. However, I see teams absolutely dooming themselves with a failure to understand it all the time.

https://www.agile-academy.com/en/agile-dictionary/spike/




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: