Agile Project Management with Kanban: Adapting from Waterfall

This chapter is for people currently using a traditional Waterfall method for product development. If your team uses Scrum, please feel free to skip to the next chapter, “Evolving from Scrum.”

Kanban is simple in structure and uses common terminology. As a result, a wide range of people can begin using it without significant trouble or prolonged explanation. As with any new method, it takes a few weeks to adjust to Kanban and a few months to master it. Nonetheless, even if you learned product development decades ago, you can quickly get started and feel productive with Kanban. After a couple of months, the increases in productivity, quality, predictability, and agility should be evident and measurable to your leadership and your team.

When I talk about “traditional Waterfall,” I mean the practice of writing specs, implementing features, and performing validation in bulk (many features at once) over the course of milestones that often span months. I’ve experienced many variations of Waterfall at Microsoft, Boeing, and other places where I’ve worked.

This chapter will help you adapt your variation of traditional Waterfall to Kanban without much fuss or hassle. I’ve even included a rude Q & A listing questions that a blunt team member might ask, followed by pragmatic answers meant to reassure, build trust in the new approach, and clearly explain how to achieve great results with Kanban.

Introducing Kanban to a Waterfall team

A traditional Waterfall team is one that likely has members who’ve been doing product development for decades. Their habits were formed long ago and have served them well over the years. Although the products they build might be buggy initially, the members of the traditional Waterfall team know how to stabilize the product at the end, drive out the bugs, and release reasonably close to the scheduled date with acceptable quality.

However, as product development has moved to shorter timelines, and long stabilization periods are no longer viable, traditional Waterfall teams may be pressured to become “agile.” This can make team members feel both uncomfortable with the notion of change and disrespected given their past accomplishments.

For a traditional Waterfall team to embrace Kanban, you need to explain why a change is necessary, utilize people’s valuable Waterfall experience, and lightly adjust their familiar methods to facilitate a smooth workflow and quick cadence. Once the team masters Kanban, it can choose to improve further by making more significant adjustments to its approach. However, the starting point can feel familiar and straightforward.

To understand why making some adjustments to Waterfall is necessary, it’s helpful to recognize where a traditional Waterfall approach breaks down:

• When traditional Waterfall is done well, you start with a solid plan everyone believes in (based on market research, prototyping, architectural design, and other planning), with clearly documented requirements and specifications and a thoughtful schedule based on known dependencies and staff allocations. Such plans typically prescribe a year or more of product development, broken into a series of milestones followed by a prolonged stabilization period.
• Unfortunately, within a few months of implementing the plan, uncertainties creep in, requirements change, dependencies shift, and people move around. As a result, the team has to update plans, specifications, and schedules and throw out or rework the portions of the product (and associated tests, if any) that are affected.
• The cycle of updates, discarded work, and rework repeats as the market shifts during product development and customers provide feedback at each milestone.
• All the plan and product churn results in numerous quality issues that often extend the already long stabilization period, frequently delaying the product release.

Ideally, every product change should receive immediate customer feedback, adjusting to market shifts daily, with no buildup of churn or other quality issues. Doing so would require a smooth flow of work through each development step and a continuous development approach that delivers completed, high-quality product improvements every day.

Scrum tries to address the breakdowns in traditional Waterfall by converting the milestones to short sprints (typically one to four weeks in length), producing customer-ready product improvements each sprint, and adjusting to customer feedback at the end of each sprint. It’s a substantial improvement, but churn still builds up during sprints, plans still need to be updated each sprint, and the flow of customer-ready product enhancements, with its immediate customer feedback, is more frequent but still not smooth or continuous.

Kanban is built for smooth and continuous delivery of customer value. It carefully controls the flow and quality of work to discover and resolve issues immediately. It limits the work in progress (what’s called inventory in manufacturing) so that churn doesn’t build up and the team and product can adjust to market shifts daily. Kanban does all this while working within the current roles and specialties of traditional Waterfall teams, making it seem familiar and straightforward.

When introducing Kanban to a Waterfall team, start by reassuring team members. Tell them, “Nearly everything you did before to develop products, you still get to do. You don’t have to learn new roles or unfamiliar terminology. We will put a big focus on quality, and we will do our best to frontload the most critical work. But you will still do day-to-day product development the way you always have. The biggest change will be the way you select what to do next. Luckily, that selection process is easy and displayed on a big board where everyone can see it.”

At this point, you can proceed to the Kanban quick-start guide (Chapter 2) using your current backlog of work as a starting point. But before you move on, here are a few points about the rest of this chapter.

• A couple of areas that might take traditional Waterfall team members by surprise are worth discussing in advance. I cover these in the next two sections: “Working in feature teams” and “Completing features before starting new ones.”
• After your feature team has gotten used to Kanban, you might choose to change how you deal with specs and bugs and how you engage with customers. I describe those changes in the sections “Dealing with specs and bugs” and “Engaging with customers.”
• To show your management and your team how Kanban is improving productivity and quality, you’ll want to measure and celebrate your progress. This can be critical to gain commitment to Kanban, it’s easy, and it provides a nice morale boost. See the “Celebrating performance improvements” section.
• Finally, I have answers to common questions in the last section, “Rude Q & A.”