The underlying triangle here: Out of time, scope, and quality, you can pick two to specify but you can't constrain all three.
Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint.
Kanban specifies fixed scope and quality, letting time be the floating factor for each task.
Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way.
There are some applications that Scrum does fit better than Kanban, notably anything tied to a real world calendar, say a scheduled live event or a school year or holiday or other seasonal concern. But yes, most businesses don't need to be time-boxed with Scrum anywhere near as much as they think they do, particularly given how much of that time is always consumed by organizational friction around the time-boxing negotiations.
(What happens if you do try to constrain and specify all three? We call that a death march. Actually, time invisibly flexes as workers cram in effort at a higher pace, until they burn out and then you're back to quality implicitly or time explicitly giving way unless you reduce scope.)
> Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way.
Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically
I think often the supposed failings of waterfall is actually the failings of large scale software development, which crop up even with agile methods (especially with stuff like SAFe).
My experience with small-scale waterfall is one of getting essentially a spreadsheet of requirements, implementing to spec, fixing a small number of bugs during QA, and then going into production on time and with exceptional quality.
There's a project I did that went from zero lines of code to production in two months, that had literally bugs discovered in a decade of operation. Made entirely possible through waterfall-style development. If you know exactly what to build, development goes fast. There is not a chance in the world that would have happened if we'd been discovering new requirements along the way.
That said, it also puts a lot more demand on well thought out requirements. The people who put together the specs were world class, smart, professional and solid engineers. Extremely particular where it mattered yet with very little bike shedding.
My experience is that developing against fixed requirements is fast and produces exceptionally high quality code. So many bugs and so much technical debt is from having to rewrite the same thing over and over because the requirements aren't set when development starts.
>My experience is that developing against fixed requirements is fast and produces exceptionally high quality code. So many bugs and so much technical debt is from having to rewrite the same thing over and over because the requirements aren't set when development starts.
I think that's why Agile was invented: for situations where requirements are not fixed. If you have fixed requirements, I don't see why you'd need Agile development in the first place, though some parts of it might be useful for just keeping everyone on track.
In a recent job, we used Scrum and it generally worked well, but we didn't have the luxury of fixed requirements. The customer needed new features on a regular basis (features which they could not have foreseen the need for beforehand), and we'd regularly give them deliveries of the version of the product we had, which they'd immediately put into use. A waterfall model would never have worked there.
I've had similar experiences with waterfall; projects running on time, over multiple years, on which the end users never reported so much as a single bug.
As you say, it demands really good requirements, which can only come from high-quality customers. Most customers are not high quality. They are low quality. They are bad. They don't know what they want and don't know how to express themselves. As you suggest, a really good requirements person can tease these details out of them, but in my experience a great many companies don't even realise how bad and incompetent a lot of their own customers are.
> Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically
This is WILDLY different to my experiences. Waterfall projects always drag out months and even years past their expected delivery. The requirements documents become bloated wish lists. Prioritisation is impossible because no one will accept cutting even the really fluffy stuff. Waterfall requires dedicated project managers who spend their whole day arguing with everyone. I admit that the quality is often higher, but that should be expected when it takes three times longer to deliver. Scrum/Agile forces teams to focus on the core value proposition, and not all the nice-to-haves. You believe this is only an issue with incompetent management, but if so, I've never seen what you consider to be competent management.
I think the better solution here is not to buy into any framework as though it's a religion. Waterfall dominated projects for decades, and it has lots of issues. Agile is dominating current ways of work, and it has lots of issues. We should be using the right tool for the job, and even then, only the parts which make sense for our product and team and culture.
My pet hate is that Scrum has somehow been dubbed as Agile, when a rigid system of meetings and planning techniques is the antithesis of agile development, which was conceived of to push back on exactly that.
I've only ever seen waterfall work with a large enough team and we'll understood problem space. That said, the two teams I was on where both of those existed it was much more productive that even the best run scrum teams I've been on.
Actually the most effective strategy I've seen is Kanban, but with a fixed release deadline.
Inevitably there are some essential tickets and some nice-to-have tickets.
For the nice-to-haves it's a case of progress or die.
Think of it as time constrained Kanban with semi-fixed scope.
The dropped tickets may carry over to a later release (if there is one), or just die forever (make it easy to cull bullshit).
P.S. From this perspective, the first thing to die is the time wasting sprint rituals that Scrum layers on top of Kanban.
No that's not scrum, as any "scrum master" will tell you ... scrum imposes it's own artificial cadence.
This is kanban ... just culminating in a release event anything from weeks to months in the future (driven by time factors independent of dev management i.e. actually having to produce something as a business). I mean nobody can seriously be proposing no time bound on kanban (please clear the board this decade?)
If you're behind schedule pausing for a ridiculous high school level show and tell will only delay you more ... and if you're ahead of schedule, just keep doing what you're doing right.
What kanban provides is visibility, how much you're getting done. Scrum sacrifices momentum for theatre.
Yes, a professor I had called it "cinnamon bun," and it's been a thing since at least the early 90s. Waterfall doesn't have to be end-to-end.
In my experience it's better to have more than a 2 week cycle though. I've seen it at 3 months and 6 months, both worked fine. Even if waterfall is end-to-end, it should still be broken up into phases for sanity checks.
Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint.
Kanban specifies fixed scope and quality, letting time be the floating factor for each task.
Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way.
There are some applications that Scrum does fit better than Kanban, notably anything tied to a real world calendar, say a scheduled live event or a school year or holiday or other seasonal concern. But yes, most businesses don't need to be time-boxed with Scrum anywhere near as much as they think they do, particularly given how much of that time is always consumed by organizational friction around the time-boxing negotiations.
(What happens if you do try to constrain and specify all three? We call that a death march. Actually, time invisibly flexes as workers cram in effort at a higher pace, until they burn out and then you're back to quality implicitly or time explicitly giving way unless you reduce scope.)