Waterfall and Scrum Are Not Opposites; Waterfall and Autonomous Teamwork Are
Here’s the original paper on Scrum from 1986 and its intention for autonomy:
Autonomy. Headquarters’ involvement is limited to providing guidance, money, and moral support at the outset. On a day-to-day basis, top management seldom intervenes; the team is free to set its own direction. In a way, top management acts as a venture capitalist. Or as one executive said, “We open up our purse but keep our mouth closed.”`
Now here’s Basecamp describing building a calendar feature with the waterfall that many organizations, even those claiming Scrum, are doing. Their flow is this:
Product manager with feature and budget -> ‘Shaping’ team imagining a solution within budget -> Cycle team executing ‘shaped’ solution
If you replace “cycle team” with Sprint team then you can map this onto Scrum as it is frequently practiced. Where the original Scrum paper clearly wanted ‘shaping’ and Sprinting to be done by one team given a feature and budget mandate, waterfall wants the input to development to be a design.
What process you follow while you code is secondary to whether you are autonomous or not. The primary question is how many strings are attached to your budget.
Lack of autonomy is bad for the product
Let’s take that calendar feature from an autonomous teamwork perspective. First the product manager keeps a simple list. One of the line items on the list is “Calendar feature: Past versions of Basecamp had calendars, and only about 10% of customers used them. Depending on the depth of implementation it might be worth spending 6 weeks for a calendar feature”.
Note that the list the PM keeps is not a fully refined, prioritized backlog. You can’t prioritize these features - you can only briefly describe them and the potential market for them. The description is brief because you don’t know the real market appetite; for instance cameras on cell phones were wildly unpopular until one day the technology got better.
Now some developer reads the list, which is fully available to everyone, and has an idea “Let’s try integrating fullcalendar.io”. If that developer has a tool like Uclusion available to him then he can send an Initiative to measure support.
The important part of this is that in waterfall world you get a crappy, limited calendar pre-designed to avoid all complexities that might or might not be expensive to implement. In the autonomous world you might get a fully realized nice calendar. And that’s exactly the result the original paper on Scrum predicts:
This kind of autonomy was evident when IBM developed its personal computer. A small group of engineers began working on the machine in a converted warehouse in remote Boca Raton, Florida. Except for quarterly corporate reviews, headquarters in Armonk, New York allowed the Boca Raton group to operate on its own. The group got the go-ahead to take unconventional steps such as selecting outside suppliers for its microprocessor and software package.
Same process for technical work
In autonomous teamwork whether it’s a customer visible feature or some form of technical debt the process is the same: lists of not fully flushed out ideas are converted by agile collaboration. Work is approved via opinions on reasonable budget and further collaborative help is asked for - not imposed.
The fact is that waterfall or not really has nothing to do with whether you follow Scrum ceremonies. Notice that the paper above doesn’t discuss any ceremony and is not even assuming software development. The important part is the level of detail in the hand off from people that can approve budget to those that use the budget.