8 ms·

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 qu

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

azophy_2 3y ago
This is a good explanation about differences between the three
- sideshowb 3y ago
  ...for anyone who already knows that waterfall isn't iterative
  - rzzzt 3y ago
    Can I start a waterfall every two weeks?
    - sideshowb 3y ago
      Sure, but if they're on the same project it might be called something else.
    - Clubber 3y ago
      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.
DangitBobby 3y ago
Of course fixing time and quality requires the ability to create accurate estimates.
- layer8 3y ago
  Not if you can reduce scope (to zero, in the worst case).
dilyevsky 3y ago
> 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
- marginalia_nu 3y ago
  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.
  - midoridensha 3y ago
    >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.
deleted 3y ago
[deleted]
pg_1234 3y ago
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.
- vikingerik 3y ago
  That's functionally scrum anyway, you're just not calling it that to avoid the ceremony, yeah.
  - kahmeal 3y ago
    The ceremony just undoes the efficiency in most cases; That's the rub.
  - pg_1234 3y ago
    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.
Clubber 3y ago
I've always understood the triangle to be cost, time, scope. Quality should not be mutable. https://www.projectmanager.com/blog/triple-constraint-project-management-time-scope-cost https://www.projectmanager.com/blog/triple-constraint-projec...
mock-possum 3y ago
Is there a longer article you have a link to, covering that triangle and the three project management strategies? It’s a fun concept.

azophy_2 3y ago

This is a good explanation about differences between the three

sideshowb 3y ago
...for anyone who already knows that waterfall isn't iterative
- rzzzt 3y ago
  Can I start a waterfall every two weeks?
  - sideshowb 3y ago
    Sure, but if they're on the same project it might be called something else.
  - Clubber 3y ago
    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.

DangitBobby 3y ago

Of course fixing time and quality requires the ability to create accurate estimates.

layer8 3y ago
Not if you can reduce scope (to zero, in the worst case).

dilyevsky 3y ago

> 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

marginalia_nu 3y ago
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.
- midoridensha 3y ago
  >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.

deleted 3y ago

[deleted]

pg_1234 3y ago

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.

vikingerik 3y ago
That's functionally scrum anyway, you're just not calling it that to avoid the ceremony, yeah.
- kahmeal 3y ago
  The ceremony just undoes the efficiency in most cases; That's the rub.
- pg_1234 3y ago
  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.

Clubber 3y ago

I've always understood the triangle to be cost, time, scope. Quality should not be mutable. https://www.projectmanager.com/blog/triple-constraint-project-management-time-scope-cost https://www.projectmanager.com/blog/triple-constraint-projec...

mock-possum 3y ago

Is there a longer article you have a link to, covering that triangle and the three project management strategies? It’s a fun concept.