1. If the people on the team can't change the process, it ain't agile
2. Sprints aren't a failure of agile, they're a failure of devops. Once you start deploying multiple times a day, nobody will care when one sprint ends and the next begins and it'll be fine
3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular than months
What about review? Code review? QA? Showing off to stakeholders? These things add a delay, and there is a 'crunch' around the end of sprints where things are artificially urgent. I am not sure that is optimal. I have not heard a reasonable solution to this, other than abandon sprints maybe?
I think this stuff works wonders when at MVP stage and number of users < 10 maybe. For mature and complex products, the type I typically have worked on it is not ideal.
Also a 'crunch' around the end of a sprint sounds like mini-waterfalls.
How I have seen sprints done is you commit to X Y Z, have a definition of done like “is in production” and then developer works on X, gets X code reviewed and so on.
If the aim is that the right amount of work is in each sprint then naturally the last day will be busy trying to get stuff reviewed.
I guess you can then get rid of the 2 weeks? Because you can measure velocity as a continuous rolling average. Retros could be continuous too and standups already are. Grooming is easy to make continuous too.
I’ve been part of teams working this way without sprints and artificial crunch on mature and large scale services, so it really isn’t a MVP/startup only deal…
Take a look at Dave Farley's Continuous Delivery YouTube channel to see the answers.
I think it boils down to "don't do that" with good arguments why and how to assure quality instead.
I'm also not sure I agree on your take on Sprints. In my mind, the value of sprints is that they provide a barrier where you should be able to go "we already loaded all our work for the next 2 weeks. If you want something done, we'll start it in N days." Done right, sprints are your defense against "can't we just do this thing".
re: sprints: You don't need a barrier against "can you do this thing". If the thing is important enough, do it; if it isn't, don't. You work on whatever the top priority is, and your sprint commitment is just a list of what the priorities were, N days ago.
(Edit: you do still need a PO willing to say "doing the thing would delay the other thing" though)
Absolutely.
> 2. Sprints aren't a failure of agile, they're a failure of devops.
I don't think so, here's the timeline: Scrum (90s), Agile (2001), DevOps (2009). So sprints have been around a long time before DevOps, the way I interpret it.
> 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular than months
How? Your event horizon spans only the next couple of iterations, everything beyond that is pure speculation.
Separately from deployments, in some less-than-ideally run organisations, management may whimsically change its mind about what the number one priority is from day to day. Two-week sprints can shield the delivery team from this, by acting as some kind of low-pass filter on thrashing priorities, to create space to get a few things entirely done.
Five years ago, we deployed once per sprint, and it was a big deal: the test pass takes this many days, the change management team needs this much time, etc. So quite often, finishing a story on day N might mean it goes out on day N+4, but finishing it on day N+1 means it'll take two more weeks, day N+18. That's where the urgency came from: that "tax" of lost time due to infrequent deploys. So there was a lot of pressure to get things into a given sprint. Hence, sprint commitments.
Now, on the same platform but with frequent deploys, we still have pressure to get a story done by a certain day sometimes, but the sprint cadence no longer affects our ability to do that. It goes when it goes. Without that pressue, we realized that sprint commitments didn't serve much purpose, so w stopped doing them, and we haven't missed them.
That's what I was referring to - it's not the sprint that matters, it's the "tax" on deployment time, which varies depending on where you are in the sprint. Take that away, and you stop caring where you are in the sprint, like a teenager in summertime losing track of the days of the week.
The motivation to batch releases was largely driven by a desire to do full end-to-end integration testing of changes between a number of entangled backend and frontend systems. It often took days to stabilise all the components in the single pre-production staging environment used for end to end integration testing, then run through the test plan. Perform batched end-to-end testing of system was the process bottleneck.
Monthly releases created similar crunch dynamics of changes being delayed by a month if they weren't stable enough to enter the monthly test cycle. Since end to end testing is the bottleneck, you don't want to feed in low quality inputs (rushed changes that are likely to cause issues and then trigger re-tests of the entire slow end to end test process).
I'm not saying this is the best way to do this, it definitely isn't, but there can be some reasoning behind it.