5 ms·

> "I simply cannot "decompose" a single feature into 500 different sub-task Jiras." Nobody can; that's the primary failure mode of waterfall. Anybody who is t

> "I simply cannot "decompose" a single feature into 500 different sub-task Jiras." Nobody can; that's the primary failure mode of waterfall. Anybody who is telling you to decompose a feature into that many subtasks might claim to be doing agile but they really are trying to do waterfall.

deleted 6y ago
[deleted]
mumblemumble 6y ago
> that's the primary failure mode of waterfall That's the primary failure mode of a straw man software development methodology called waterfall that Scrum practitioners like to use as a bogeyman to appeal to for rhetorical purposes during the inevitable arguments about niggly little details of how to implement Scrum during sprint retrospectives. I've never actually done real waterfall, but I did study it way back when I was in college, and I have worked in government contracts, which tend to handle the work in a way that is similar to the waterfall I read about in school. One thing I distinctly remember is that it was designed to be a flexible and iterative methodology that would have been difficult to cram into a ticketing system in the first place, let alone cram into Jira while simultaneously carving the work into tiny pieces, up front, all at once. FWIW, the only place I've ever been asked to do something like that is in ostensible Scrum shops. In fact, the only time I've ever seen anything that looks like the Waterfall of scrum lore is in shops that are trying to do Scrum. I am beginning to suspect that the Waterfall of Scrum lore isn't actually a thing that happens outside of Scrum at all. It's actually what naturally tends to emerge when you try to apply Scrum methodology in a situation where something along the lines of the real, textbook waterfall model would have been more appropriate. As a concrete example, I currently work at a team that ostensibly uses Scrum, but where QA is a separate department with its own practices that the dev team does not control. They do still want some ability to anticipate work that's coming their way, though, so they're monitoring the scrum board for that purpose. This is the moment where it gets messy, because we're then asked to document things ahead of time, and it's a minor crisis if we keep it flexible during the sprint because any changes to the set of tickets becomes an inevitable hassle as they complain that we've screwed up work product that they generate based on those tickets. It's absolutely something straight out of waterfall horror stories from Scrum lore. But it's only happening because we're doggedly insisting on something that's at least cosmetically similar to scrum. If we weren't doing that, we'd be freer to choose modes of interaction and business artifacts that are better suited to the reality we occupy.
- Jtsummers 6y ago
  A reason you often see Waterfall-in-Scrum is because people who were using Waterfall wanted to get away from it, and they made it as far as Scrum (the name). They usually keep the same practices of massive design/spec documents that are developed in advance. They try to plan out the next 20 sprints (hah, I saw a team that tried to plan out 60 sprints 4-week sprints, it was kind of hilarious if I wasn't dying inside from the thought of it). The biggest difference for Waterfall-in-Scrum versus Waterfall is that they've sufficiently (hopefully) decomposed tasks to have short target dates for delivering something to a test team or facility. They don't use it to get feedback from customers (the actual users, not the ones writing the checks). They don't use it to replan when things go wrong. They just use the whip and OT and get back on track.
- wpietri 6y ago
  Waterfall was the dominant model of software engineering up until the late 1990s. It is how managers want software (and projects generally) to work. I promise, it was real! Back then, a quarterly release cycle was fast; 12-18 months was more common. With the rise of the Internet, everybody knew that couldn't work, but didn't know what to do, so there was a lot of experimentation in the late 1990s: Scrum, FDD, Crystal, Extreme Programming, and more I've forgotten or that were never named. Out of this chaos, eventually came order. It turns out what mattered most in practice, just like before, was pleasing managers and executives. Effectiveness was generally secondary. So what we ended up dominating is Scrum, the most waterfall of Agile processes. Most shops "doing Agile" these days are still following a top-down, control-oriented, ineffective and unrealistic process, just like before. But now they use Agile labels for their mostly-unchanged process, albeit with a faster release cadence.
  - james_s_tayler 6y ago
    Nailed it.
  - einpoklum 6y ago
    In much (most?) of software being worked on these days, * A quarterly release cycle is indeed fast. * 12-18 months between releases (ignoring perhaps bugfix/point releases) is quite common. You write that "everybody knew that couldn't work" - for some projects. Definitely agree with your second paragraph - except that Agile labels can be used even without a faster release cadence :-)

deleted 6y ago

[deleted]

mumblemumble 6y ago

> that's the primary failure mode of waterfall That's the primary failure mode of a straw man software development methodology called waterfall that Scrum practitioners like to use as a bogeyman to appeal to for rhetorical purposes during the inevitable arguments about niggly little details of how to implement Scrum during sprint retrospectives. I've never actually done real waterfall, but I did study it way back when I was in college, and I have worked in government contracts, which tend to handle the work in a way that is similar to the waterfall I read about in school. One thing I distinctly remember is that it was designed to be a flexible and iterative methodology that would have been difficult to cram into a ticketing system in the first place, let alone cram into Jira while simultaneously carving the work into tiny pieces, up front, all at once. FWIW, the only place I've ever been asked to do something like that is in ostensible Scrum shops. In fact, the only time I've ever seen anything that looks like the Waterfall of scrum lore is in shops that are trying to do Scrum. I am beginning to suspect that the Waterfall of Scrum lore isn't actually a thing that happens outside of Scrum at all. It's actually what naturally tends to emerge when you try to apply Scrum methodology in a situation where something along the lines of the real, textbook waterfall model would have been more appropriate. As a concrete example, I currently work at a team that ostensibly uses Scrum, but where QA is a separate department with its own practices that the dev team does not control. They do still want some ability to anticipate work that's coming their way, though, so they're monitoring the scrum board for that purpose. This is the moment where it gets messy, because we're then asked to document things ahead of time, and it's a minor crisis if we keep it flexible during the sprint because any changes to the set of tickets becomes an inevitable hassle as they complain that we've screwed up work product that they generate based on those tickets. It's absolutely something straight out of waterfall horror stories from Scrum lore. But it's only happening because we're doggedly insisting on something that's at least cosmetically similar to scrum. If we weren't doing that, we'd be freer to choose modes of interaction and business artifacts that are better suited to the reality we occupy.

Jtsummers 6y ago
A reason you often see Waterfall-in-Scrum is because people who were using Waterfall wanted to get away from it, and they made it as far as Scrum (the name). They usually keep the same practices of massive design/spec documents that are developed in advance. They try to plan out the next 20 sprints (hah, I saw a team that tried to plan out 60 sprints 4-week sprints, it was kind of hilarious if I wasn't dying inside from the thought of it). The biggest difference for Waterfall-in-Scrum versus Waterfall is that they've sufficiently (hopefully) decomposed tasks to have short target dates for delivering something to a test team or facility. They don't use it to get feedback from customers (the actual users, not the ones writing the checks). They don't use it to replan when things go wrong. They just use the whip and OT and get back on track.
wpietri 6y ago
Waterfall was the dominant model of software engineering up until the late 1990s. It is how managers want software (and projects generally) to work. I promise, it was real! Back then, a quarterly release cycle was fast; 12-18 months was more common. With the rise of the Internet, everybody knew that couldn't work, but didn't know what to do, so there was a lot of experimentation in the late 1990s: Scrum, FDD, Crystal, Extreme Programming, and more I've forgotten or that were never named. Out of this chaos, eventually came order. It turns out what mattered most in practice, just like before, was pleasing managers and executives. Effectiveness was generally secondary. So what we ended up dominating is Scrum, the most waterfall of Agile processes. Most shops "doing Agile" these days are still following a top-down, control-oriented, ineffective and unrealistic process, just like before. But now they use Agile labels for their mostly-unchanged process, albeit with a faster release cadence.
- james_s_tayler 6y ago
  Nailed it.
- einpoklum 6y ago
  In much (most?) of software being worked on these days, * A quarterly release cycle is indeed fast. * 12-18 months between releases (ignoring perhaps bugfix/point releases) is quite common. You write that "everybody knew that couldn't work" - for some projects. Definitely agree with your second paragraph - except that Agile labels can be used even without a faster release cadence :-)