Agile Project Management with Kanban: Adapting from Waterfall

Completing features before starting new ones

Some traditional Waterfall teams specify (and review) every feature in a release before any features are implemented, and some implement every feature before any are validated. Some Waterfall teams arrange release work into a series of Specify/Implement/Validate milestones. Within each milestone, all features for that milestone are specified before they are implemented and implemented before they are validated. This traditional Waterfall approach is reminiscent of batch processing jobs with mainframe computers.

The batch approach in traditional Waterfall is simple and keeps team members focused. However, it can be inefficient and inflexible if the batches are large and can’t be easily changed or reordered. Arguably, the biggest change for traditional Waterfall folks adapting to Kanban is to work on very small batches of items, constrained by WIP limits. The active cards in a step form the current batch. Instead of milestones or releases lasting months or even years, the batches last only days at a time. (I talk about coordinating Kanban work within much larger projects in Chapter 7, “Using Kanban within large organizations.”)

Although the small batches in Kanban are a new concept, traditional Waterfall folks adapt quickly because the steps they follow to process each batch are the same as they were in traditional Waterfall. They just process only a few items at a time. Typically, two areas of confusion or surprise come with the shift to small batches:

• There’s initial confusion about what to do when the WIP limits restrict the flow of batches. I cover those cases in the troubleshooting section of the Kanban quick-start guide (Chapter 2).
• There’s confusion or surprise about the increased frequency of cross-discipline interaction. Because Kanban uses very small batches, people responsible for different steps engage with one another more often. At first, this can seem like a distraction. Personal expectations of quiet time, appropriate engagement, and other professional courtesies develop quickly. In time, team members view the increased interaction as a significant improvement because it catches design and implementation flaws early, before they permeate the entire release and become more expensive to repair.

To smooth the adaptation to small batches, tell your team, “We’re all familiar with specifying features, implementing them, and validating that they work well for customers. We used to specify, implement, and validate a whole bunch of features at once. It was easy to organize around large batches, but the world changes quickly, and turning big boats takes time. We’re now adopting small batches, moving a card on our signboard as each feature, each bit of customer value, gets specified, implemented, and validated. The cards make tracking these small batches easy, and the small batches make it easier to keep pace with the world and the needs of our customers.”

Once your feature team is used to meeting together for the daily standup, and the team has become familiar with the dynamics and extra interaction of working on small batches, you might want to introduce and make a couple of more adjustments to further improve your smooth and continuous delivery of customer value. You might want to change how you deal with specs and bugs and how you engage with customers. I describe those changes in the next two sections.