Agile Project Management with Kanban: Adapting from Waterfall

Engaging with customers

Traditional Waterfall teams typically engage with customers during planning (before work on the release begins), every one to six months at the end of stabilization for each milestone (perhaps as part of a preview program), and during final release stabilization (often as part of a beta program).

As experienced engineers know, customer feedback is invaluable for specifying, implementing, and validating product improvements. Customer engagement with traditional Waterfall teams is limited because the product is usually too buggy or incomplete to use. Customers can’t provide actionable feedback when they can’t use the product. Instead, customers must wait until the end of stabilization periods, when the product has the fewest-known bugs.

In contrast, Kanban provides an opportunity to engage with customers at whatever cadence the team or its customers finds most convenient, including continuously with customers who are onsite. Kanban enables this because when a task is through validation, it’s ready for production use.

Naturally, you want to try out product improvements with a limited number of customers first, and gauge their reactions, before publishing those improvements to your entire customer base. One common approach is to first have the entire product development team try the latest version, then share it through an early adopter program, then publish it to a broader preview audience, and then finally release it to all your customers. (I describe an example in the following “Inside Xbox” section.)

The customer feedback you get along the way can be used to hold back changes that don’t work, adjust designs, reorder pending work, find subtle or rare bugs, fill gaps in usability scenarios, and expand features in areas that customers love. Since Kanban limits work in progress (small batches), it’s easy to adjust to customer input within days.

To take advantage of the customer feedback opportunity, you need to establish a preview program, an early adopter program, and a way for the entire product development team to try the latest version. Here are some possibilities:

• Many traditional Waterfall teams have beta programs already. You can repurpose your beta program as a preview program.
• To establish an early adopter program, you can engage the most active members of your beta audience or hand-select key customers and offer them early adopter status as a perk.
• To expose the entire product team to the latest builds, follow the steps I outline in Chapter 6.

Soon, you’ll be enjoying greater confidence, higher quality and usability, and more delighted customers. There’s nothing quite like engaged customers providing actionable feedback on working products.

The last, and arguably most critical, step to ensure that your team and your management commit to Kanban is to measure the great results you’re getting, and then celebrate your success. That’s the topic of the next section.

Inside Xbox

Xbox One launched in the fall of 2013, and at the time of this writing has shipped new releases of the platform every month since. The Xbox One product team uses a variety of methodologies: Scrum, Scrummerfall (traditional Waterfall with short, fixed-length milestones called “sprints”), variants of Extreme Programming (XP), and Kanban. All of these techniques enable frequent customer feedback.

The move to monthly releases had its challenges, but was surprisingly smooth and natural. In hindsight, I feel that two key changes made this smooth transition possible:

• Roughly 18 months in advance, we synchronized all enterprise Scrum and Scrummerfall sprints and XP iterations to match a shared 4-week cadence. Kanban releases continuously and can match any cadence, so the Kanban teams didn’t need to adjust.
• In the months leading up to the launch, we released new platform builds to the Xbox product team weekly, then to the early adopter program the week after, and then to a preview audience monthly. We released fixes immediately for issues found by each audience. Once Xbox One launched, we simply continued that release cadence and approach, adding a broad release to all customers a few weeks after the preview audience received it.
• Establishing the various release audiences was pretty easy, relatively speaking.
• We already had a release mechanism for the weekly Xbox product team builds. It’s called “dog food” (as in “eating our own dog food”), and has been around since the first version of the Xbox. Naturally, we needed to update the program for Xbox One, but that was anticipated.
• We already had a passionate early adopter program. Basically, we ask all full-time Microsoft employees if they’re interested in early releases of Xbox—first come, first served. The list fills within hours. Again, we needed to update our deployment process for Xbox One, but that was expected.
• And we already had a passionate Xbox beta audience that we could convert over to Xbox One preview. This was the most work—not to get the audience, but to reconfigure the beta feedback site, logistics, and tooling to a monthly release cadence.
• Now that Xbox is releasing once a month, we never want to go back. Our customers love the new features and responsiveness to requests. Our engineers love the predictability, the decreased churn between releases, and the reduced pressure (if your feature misses one month, it can always go out the next). And our management loves the positive press we’ve received and how that’s translated to the bottom line.