Focusing improvements and batch processing ("Scrumfall")

I was pondering this image - and relate it to “Waterfall” or “Scrumfall”, in either case - how larger organizations tend to arrange work:

I made some interesting discoveries when comparing this to how most larger organizations do Scrum:

It gets even worse when we have “Pure Scrumfall” where each work step is done by a separate Scrum team:

Or, in other words: “Doing Scrum could slash your performance in half if you’re optimizing for utilization rather than throughput.”

I’ll leave it as an exercise to the reader what happens when we optimize activity “G” for utilization (e.g. cutting headcount until they’re 100% utilized in each Sprint).

1 Like

The statement…

… does not hold simply because what you described is a Scrumbut and not proper Scrum.

Now as much as Scrum has too many issues to really make a difference in the large scheme of things, misusing it to show it is inadequate is not necessary. Scrum has enough issues on its own to make it an interesting improvement object. :slight_smile:

1 Like

Oh absolutely, it’s a Scrumbut.
Yet, unfortunately a very common form of “Enterprise Scrum”, where a “development team” does pretty much everything except UAT and deployment to production.

I agree with your core point that Scrum itself has a lot of issues in and of itself.

Just wanted to highlight how harmful Scrum can be as an “improvement” when not used properly.

1 Like

Well, yes. But Scrum is harmful enough even when used properly! It doesn’t need that kind of help! :smiley:

1 Like