Kanban: The Secret of High-Performing Teams at Microsoft

Note: This page is updated at Kanban for High-Performance Teams.

If you are a project manager or a program manager, or aspiring to be, one of the best project management tools you can add to your toolbox is the Kanban. In fact, if somebody were to ask me, what’s the single best way to exponentially improve project execution, I would probably say, the answer is Kanban. (Well, I might first say, get my book, Getting Results the Agile Way, and adopt Agile Results

A Kanban is a simple project management tool. It enables you to visualize your workflow, limit your work in progress, and optimize your “cycle time” (the time it takes to complete one item.) For software development projects, this is a big deal. It helps you find bottlenecks and push quality upstream. Ultimately, you shape your process to flow more value as efficiently and effectively as possible, “just in time.” Another way to think of it is, your users “pull” value through your development chain, while you streamline your process.

I first got introduced to Kanbans, several years ago, by one of the best and brightest in software engineering, Corey Ladas (author of Scrumban.) My introduction was a “learn by doing” exercise.

Identify State Changes in Your Workflow

We went to the whiteboard and Corey has me identify the main states of my project workflow. While it was iterative, and a lot of work was done in parallel, the main stages were:

Analysis, Design, Development, Test, and Release. It looked something like this:

Identify Work Items

Next, Corey asked me to identify the “things” or “items” that I would show on my Kanban. I had a hard time breaking things down into useful units until I used a simple test. What’s the smallest, most useful thing I could demo to users? For simplicity, let’s just say I broke things down into features and user stories. In this case, a user story was simply a persona-based scenario with a goal. In my case, I also needed some “system” stories. The bottom line was that each of these was a “chunk” of value that I would ship to users. Corey had me name some of these items and write them down on stickies. He then had me place them wherever they were currently at on my Kanban. It looked something like this:

What surprised me was that he didn’t ask me to change our team’s process. The goal was simply to reflect whatever process we were already using. The most important thing was really to identify the most meaningful state changes in our workflow, and to identify the work items that flow through it. He said the power of the Kanban is that we would tune our process over time, with real data and real results. It’s a living thing. And it’s a visual thing.

Set Limits for Work in Progress

The next thing Corey had me do was to set a limit for how many items should be actively in development at any given time. I struggled here at first because I was used to having a lot of work in flight. He pointed out the problem with a lot of work in flight is that there’s thrashing, and more time spent context switching than actually finishing the work. Worse, if we’re not closing things down, then we aren’t flowing value. He said, to keep it simple, as an experiment, set the limit at 3. Find out what your team can do. For example, with focus, how quickly can we close down an item? Where does the bottleneck happen? Which resources are idle? Could idle developers pair up with testers and unblock test, for example? He got me thinking.

Push Quality Upstream

This is where the magic happened. Corey asked me to identify some of the most common issues found during Test. I rattled off a few common problems. He then asked me what I could check for before entering test. We then repeated this process a few times until we had a few simple checks before we leave Analysis, and before we leave Design, and before we leave Development.

It sounds so simple, and it is,   But the big deal was having it all at a glance, on the whiteboard.  We could now easily get the right people at the board, having the right conversations.

A Living Process

The beauty is that we ended up with a unique process for our team -- built by us, built for us, and optimized by us. As a team, we could now all visualize our process. We could easily see our bottlenecks. We could easily add quality checks. We could easily add more states to our Kanban if we needed more fine-grained visibility. We basically achieved a highly-flexible, highly relevant process that struck a balance between self-organization and workflow specialization.

Kanban for Execution Excellence

That was the start of my Kanban adventures, long ago. In the years since, I’ve experimented with Kanbans, personal kanbans, Kanban tools, and various approaches. The Kanban has proven itself time and again for me as one of my most effective project management tools. It really is “just enough process” combined with a focus on flowing value and improving quality. It’s one of the best tools I’ve used for driving execution excellence across people and teams in an empowering and self-directed way.

When the question is, “How do we improve our execution?” … even if Kanban is not the answer, it’s very often as good place to start. After all, if you can show somebody your Kanban with current activity, chances are you can find the bottlenecks and optimization opportunities. At the minimum, you’ll have a shared frame of reference, the visualization of your process, which is a great way to dive deeper to troubleshoot any execution issues.

You Might Also Like

• Agile Methodology in Microsoft patterns & practices
• Idea to Done: How I Use a Personal Kanban for Getting Results
• Methodologies at a Glance

Comments

• Anonymous
  May 13, 2012
  I don't see any 'pull' happening here?

• Anonymous
  May 13, 2012
  @ Johan -- The "pull" part is the work items (Kanban cards) that reflect customer demand.   Rather than "push" things out to users and hope they want it, the idea is to be demand-driven, and respond to customer requests and fulfill demand as efficiently and effectively as possible.

• Anonymous
  May 31, 2012
  Do you use physical whiteboard or virtual/electronic board?

• Anonymous
  June 01, 2012
  @ Dmitry -- Great question. I use both.  I prefer a physical whiteboard.  I even like walls in the halls. For the personal scenario, I actually like the Word doc.  It's simple and I can take it everywhere.  But I also will use the whiteboard in my office.  It's quick and dirty and in my face. For the team scenario, I typically use a wall.  I stick those really large white sheet post its on the wall to be the Kanban.  Then I use little yellow stickies.   Electronically, I've used Agile Zen, a few others like it, and some TFS add-ins.

• Anonymous
  June 22, 2016
  i find this post of great help