Do Agile 'Sprints' Benefit Software Developers?

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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

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/