Loading...
Quick Links

Kanban: The Secret of High-Performing Teams at Microsoft

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 Kanban, 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:

Stages in Project Workflow

 

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:

Stages in Project Workflow

 

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.

Stages in Project Workflow

 

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.

Share This Post
6 Comments
  1. Good article, to the point and shows clear value and ease of adoption. I am trying to develop interest in Kanban at our company to manage maintenance and support work for several of our legacy applications in an IT environment.
    The main driver from my perspective is just in time delivery of quality and value to the business customer without waiting for an artificial sprint or release to occur. it also cuts down on the overhead of pauses as the planning, execution and process improvements are immediate. I also like the option of setting exit agreements for each of the process phases so as you say drives quality upstream.
    Thanks
    Chris.

    Reply
  2. Our deveopment teams use agile scrum. Our business teams are partially strategic/partially operational. Any suggestions for implementing Kanbans within the business teams?

    Reply
  3. Hello J.D.
    I second Chris and Dennis question. I would like to know your opinion or experience about it!

    Thanks

    Reply
  4. @ Chris — Thank you.

    Well put — “just in time delivery of quality and value to the business customer without waiting for an artificial sprint or release to occur”

    @ Dennis — It sounds like you’re in a scenario I’ve been in a few times.

    Here’s what I did:
    1. I created demand by quizzing people in the hall to see how well they could articulate work in flight, what the goals were for the week, what the impact was last week, etc.
    2. I proposed a “pilot” where we’d meet on Mondays as a quick sync up to get everybody on the same page in terms of priorities, to save us time throughout the week by 1) avoid working on the wrong things, 2) finding opportunities to pair up, 3) practice articulating value, 4) helping keep focus, 5) getting deliberate about what we let go, 6) learning our true capacity
    3. I got my manager’s support by exposing the lack of clarity on priorities for the week, and even for the day, and how all of our work connected to customer impact
    4. On Mondays, we gathered around a wall in the hall. On the wall, I had 3 big white sticky posters: To Do, Doing, and Done.

    I started off with a highlight of priorities/events for the week all up, and then led with a brief summary of my 3 wins/highlights from the previous week, and the 3 wins I’m focused on for this week.

    I then went around the team and asked each person their wins/highlights from last week (max of 3) and their max of 3 wins they wanted to accomplish for this week. If it turned into a long-winded explanation of their activities, I’d ask again, what’s the win, or what’s the outcome, or what’s the output.

    I coached everybody to remember we all have laundry lists of things to do, bubble up to 3 wins/outcomes, not activities, not tasks, and share the “impact.”

    As we went around I would continue to capture using yellow stickies on the wall with a black marker. This made it very easy to shuffle items, refactor, etc.

    5. At the start of the next week, I’d do a quick recap of key accomplishments from the previous week.

    Usually what happens is people suddenly become aware that they had no idea what other people were working on. Now they care. Now they get curious. Now they want to align or pair up on things, and team up toward common goals.

    The most important thing, aside from clarity, is a sense of progress. If the stickies on the wall reflected things that were too big for progress within the week, I’d ask folks to break them down into something tangible and “doable” for this week (while of course, keeping the big picture in mind.)

    @ Fabio — Let me know if that helps.

    Reply
  5. Sounds great, easy, and straight forward. Do you have a good reference that can fill in details?

    Reply
  6. Thank you for sharing this great post about Kanban

    Reply

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Please complete this equation so we know you’re not a robot. *

− 2 = 1

Thanks for submitting your comment!
You must be logged in to comment.