Kanban Portfolio View – continued

(Continued from Kanban Portfolio view and the 3 core rules. This is the conclusion of Part 2 in the Scrum Alone is Not Enough series.)

2. Limit Work In Progress

We know from queuing theory, psychology of multi-tasking, and empirical evidence (Rally study, my summary of the Rally Study) that more Work in Progress means less work gets done overall. This leads to the second Kanban rule: Limit Your Work in Progress.

Work that hasn’t been deployed, shipped, or otherwise delivered to a customer has no real value. Value is only realized when the work is available for use by the customer.

The simplest way to Limit Your Work in Progress is to just watch for a few weeks how much work exists in each column. Make this your initial WIP (Work In Progress) Limit. The idea is that we shouldn’t start new work before the existing work gets to done. Once each column has a WIP limit and the columns fill up, then we’re forced to move downstream to help get the most downstream work to truly done.

In the context of the Bookstore:

In the above example, both Steve and Sarah’s development Teams have no problem staying within their WIP limits of one. However, so much work has been done in the past week that the Online Help Team is swamped and falling behind. Improvements we make at the development Team level at this stage would just serve to build out more product that doesn’t have online help. Instead, Team members from these Teams should volunteer to take on Online Help related work as part of their Sprint Commitment until the issue is solved. If this is a persistent problem, the organization needs to consider a more systemic fix – either finding more people to create the online help, or to include the online help in the Sprint level Definition of Done.

3. Measure and Improve

The third and final core Kanban rule.

Too often we focus our energy improving the productivity of the development teams even when that won’t change the amount of value delivered to the customer. A simple test: will doubling the productivity of a development team double the amount of value delivered to the customer? If not, then the development team isn’t what needs to improve first.

Kanban affords us many opportunities to measure so we can know where to focus our energy to get the best improvement. The trick is to use these measurements judiciously.

• Cycle Time – measures the moment the team starts work on a request until it’s delivered to production.
• Lead time – measures the moment that a request comes from the customer until it’s delivered.

Which to measure first? In many cases, all we control is the Cycle Time. Unfortunately, if this isn’t the major source of delay, then improving productivity here won’t make a major difference to the customer.  Lead Time is what the customer really sees, as their request enters the system and emerges sometime later.

The measurements (often shown via a Cumulative Flow Diagram) show us where our limited improvement energy is most likely to bear fruit.

In the example above, we can see the bottleneck (online help) is downstream of our development teams. We have already determined by looking at the WIP that making a significant change in the productivity of our development teams wouldn’t make any real difference in how quickly the customer received working software. So the challenge now is identifying that and determining how to get the value to the user quickly.

In many situations I encounter, there is a formal signoff before the application is deployed. In others, there is formal notification procedure to the end users. If this signoff or notification only happens once every four weeks, then the average item waits an additional two weeks after work on it is completed, while accruing no additional value. While these waits can’t be wholly eliminated, the simplest thing to do is have them happen more frequently. Instead of once every four weeks, make it weekly. This cuts the average delay from two weeks to three days. Still not perfect, but tolerable if signoffs are required.

Once we’ve made our first improvement, wait for a few weeks, gather more data, and measure again.

In the case of the SmallestOnlineBookStore we can also see that Ideas are taking from ten to twenty weeks to get from the proposed stage to part of the Common Product Backlog. (The picture below shows an unrealistically smooth development and deployment process.)

This time it’s clear that if we doubled the productivity of the development Team, we would double the value delivered to the customer, so in this case improving the Team’s capacity will help.

Warning – don’t confuse a CFD (Cumulative Flow Diagram) or other measurement with the real world. A measurement is just a hint to go find out what is really happening. In the world of Lean and Toyota, this is called a Genchi Genbutsu. Take a walk and talk to the people doing the work. Find out what is really going on.

Once we understand what our basic Kanban system is telling us, it often helps to track additional information by categorizing as follows:

• Production Support/High Priority Work
• Work for Other Teams
• Interruptions

Production Support/High Priority Work

A team that has a product live in the field might have to handle production support. When that happens our goal is to resolve the issue but also highlight the cost of handling additional work. In the long run the team need to reduce the defects that result in production support problems. Agile Engineering techniques (an upcoming post) will highlight approaches to solving this problem.

Working for/with Other Teams

When working in a multi-team environment we have to accept that some portion of each team’s time will be set aside to help their peers, even though this work won’t directly advance the features on our own Products. When we use Feature Teams we lessen the burden but we will still need to set aside time. Many Teams just allocate a fixed amount of their Sprint Capacity to helping their neighbouring Teams. In this case, during Sprint Planning the Team commits to helping other Teams up to that preset limit. The limit is usually agreed on in advance among the ScrumMasters and Product Owners of the respective Teams. As the reality of work tells what is really required, you can change the amount for future sprints.

Interruptions

This is any other work (not High Priority or Work for Other Teams) that arrives outside of the Product Backlog and Sprint Planning meeting.  Often it arrives in the form of “Could you do me a favour?” but sometimes there is no ask, it’s just demanded. This is the source of much of the “dark work” mentioned in Part I. In the best of environments, the ScrumMaster has a seat next to the team room door. When an interruption arrives the ScrumMaster walks the person to the Kanban wall and shows them what other work will be harmed or delayed by dealing with interruption. If the person has enough power or influence they may insist their problem is addressed anyway. In that case, the Kanban wall and CFD can help everyone see the cost of interruptions.

Depending on how much work we have in these three categories, we can use a simple informal measure of this work by just counting the number of items in each category (Production Support, Other Teams, and Interruptions) per sprint and display it next to the CFD. This provides a simple visual representation and will show that the Sprints with the highest volume of these ultimately delivered less value.

Our goal here is to make clear the linkage between additional work and productivity.

If the volume is high enough that we require a more sophisticated model, we could go further and create a swim lane or row for each category (Production Support, Other Teams, and Interruptions) and then model them in our CFD. For the SmallestOnlineBookStore it might look like:

They decided to create dedicated lanes for the Production Support and Interruptions. These dedicated lanes highlight that while this work maybe necessary it reduces the productivity of the development teams. They also help keep this work highly visible.

When it comes to work for other Teams, they’ve chosen a different coloured card to help with tracking, but otherwise have included it as part of normal sprint work to indicate that this an expected normal activity.

Use the data you’ve gathered here to work with your peers – your goal is to reduce the rate of interruptions and eliminate many production support issues by raising quality (see the upcoming post on Agile Engineering Practices).

Next Steps

Now that you have your first Portfolio Kanban board, and you know how to measure and improve, keep reviewing with all Team members once a week. Make it a regular rhythm or cadence. From time to time, review not just the content but also the board structure.

• Use it as a tool to start conversations and keep all work out in the open.
• Ensure your peers are involved in updating it so they feel ownership of the information.
• Keep it on real wall – if at all humanly possible, keep it on a physical wall, rather than in digital form. A wall that people will walk by multiple times a day and be reminded of the information. In addition, interacting with objects in the real world stimulates the brain in ways that a picture displayed on a large screen TV does not.
• Force Teams and the whole organization to make real prioritization decisions instead of just dumping more work in Team members’ laps.

I recommend not tracking individual stories or tasks at the Sprint level on this board because it sends a signal to management that the individual item’s progress should be tracked. It also signals to Team members that their Sprint level work is being watched and it sometimes becomes a tool to micromanage Team members, when the focus of Scrum is the opposite. Inside each Sprint, the Team (not the ScrumMaster) should have complete control over how their work is tracked.

Used well, a Portfolio Kanban Wall can help highlight where the improvement is required to improve the throughput of the whole organization, and not just one Team. Coupled with an Ongoing Organizational Improvement Team, it can be a powerful catalyst for change.

Other Sources

Karl Scotland – Portfolio Kanban

Jason Little – Designing an Enterprise Portfolio Kanban Board

Pawel Brodzinski – Portfolio Management with Kanban and Portfolio Kanban – Why Should I Care

Sandy Mamoli – Portfolio Kanban

Klaus Leopold & Troy Magennis – Using Blocker Clustering, Defect Clustering, and Prioritization for Process Improvement

Mark Levison

Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.