Fixing the work size means fixing the amount of work in progress.
That can work on two levels: the number of tasks in process for a given project, what I’ll call kanban-in-the-small, and the number of projects in process, what I’ll callkanban-in-the-large.
Kanban is a system of seeing the work in progress and knowing when it’s time to put more work items in the queue to be worked on. Kanban literally means a signboard, as in Toyota Production System [Ohn88].
The team can see the work in progress—one feature and the work yet to do, all on one board.
For example, in all serial life-cycle projects, you have a list of features.
Most iterative and incremental life-cycle projects have a similar long list of features. That feature list changes and tends to grow the longer the project is. In agile projects, there is a product backlog that is reranked for each timebox, and the team takes the next chunk of what they think they can complete off the backlog.
One of the best ways to make kanban systems work is to think of each entry in a product backlog as its own minimum marketable feature (MMF); see Software by Numbers: Low-Risk, High-Return Development [DCH03]. A project team works on just one thing—a minimum mar- ketable feature—until that MMF is complete. When that MMF is com- plete, the team can release the product.
Why is an MMF so important? It’s because that’s the basis of project portfolio management. Projects don’t matter; the set of MMFs you are ready to release is what your customers buy, as we discussed earlier. A completed MMF provides value to the organization.
When a team uses a kanban system, the team limits the number of tasks in progress at any time. At Agile 2007, Arlo Belshee described what he called naked planning,1 a way to limit what the team sees to no more than seven MMFs. The team works on one MMF at a time.
There is no minimum or maximum feature size, but the customer who
1. See http://joearnold.com/2008/03/naked-planning-kanban-simplified/ for a video brief description of some of Arlo’s informal talks at Agile 2007.
STABILIZE THENUMBER OFWORKITEMS INPROGRESS 133
requests the feature tends to ask for smaller features to limit the time the team is unavailable to work on new features.
You don’t need to have a queue of just seven items as Arlo describes.
Your queue can be any size. The key with kanban is that enough people work on one MMF andcomplete it before taking another feature of the queue.
With kanban systems, your project team can even work on multiple MMFs as long as the team can release the product once one MMF is complete. This means the team has to have great source control so the team can work on multiple MMFs and still be able to release as soon as one MMF is complete.
To use kanban effectively, the team must keep a sustainable pace, and someone (or some defined set of people) decides what the ranking of each waiting item is. But, the team doesn’t care what they work on.
They just take the next item off the list. That’s why you can use kanban for projects as a whole to manage the whole portfolio and for a given project to manage when you complete each feature.
9.4.1 Fix the Number of Tasks In-Process, Kanban-in-the-Small
One way to avoid projects but still manage the portfolio is to stabilize the number of feature sets in process. Here you can see that one feature set, a minimally marketable feature set, is in progress. That feature set has seven tasks. Of those seven, four have not yet been started, two are in progress, and one is done. Once all the tasks are complete, the team can release the MMF.
To Do:
Minimum Marketable Feature Sets
In Progress Done
Tasks
These tasks arise from the first MMF on the left
STABILIZE THENUMBER OFWORKITEMS INPROGRESS 134
When you stabilize the number of in-process tasks, especially if you are able to define a minimum marketable feature set as a relatively small number of tasks, you see a number of benefits. With so few in-process tasks, people actively work together to complete tasks.
• Projects complete faster because there’s no (or at least much less) wasted work.
• Because you’re implementing by feature, the team and you can see the project’s progress easily.
9.4.2 Fix the Number of Projects In-Process, Kanban-in-the-Large Some management teams, even when they’ve ranked the portfolio, have a difficult time assigning teams to just one project until that project is complete. But aside from the benefits to the team of avoiding multi- tasking, you receive a ton of benefits by fixing the number of projects underway:
• You know you are never going to starve a project of its necessary people. That’s because you never assign more projects than you have teams.
• The teams all learn all the projects. You don’t have to worry about cross-training, because the idea of specializing in types of projects goes away.
• Developers (or testers or writers or whomever) never have to worry about projects that are like albatrosses. That’s because the team has responsibility for the project, not management. And, the team may not be assigned to this project each time a particular product needs more work.
• Projects complete faster because there’s no competition from other projects.
• It’s easy to organize your project portfolio, because you and the organization’s leaders define what the organization needs to work onnow and what can be postponed until the next evaluation.
Any project with any life cycle can use a kanban queue. It might look different depending on your life cycle. In the picture on the following page, you can see how an organization that wants three projects in process for one team has queue limits on what’s ready to start (seven items), what can be in the development and review queue (four items), what can be in test (three), and what can be in final review (one).
STABILIZE THENUMBER OFWORKITEMS INPROGRESS 135
Kanban for software, whether you apply it to a portfolio or to a single project, has this requirement: all of the items in the queue, the MMFs, must be roughly the same size.
The MMFs must be something the team can complete in a relatively short period of time, because there is no timebox to maintain the team’s rhythm. Instead, the team’s rhythm arises from completing work.
This approach to the project portfolio requires significant discipline from every manager in the organization. As soon as one person tries to push his or her project ahead of another or ask a technical person to multitask, kanban-in-the-large falls apart.
9.4.3 When You Can’t Fix the Work Size
Some projects have an ebb and flow. Some teams have to account for maintenance work or other product support work in their projects. You can still use kanban. As the team completes one MMF, they take their next chunk of work from the queue labeled “Urgent”, for example.
FIX THEQUEUELENGTH FOR ATEAM 136
To Do:
Minimum Marketable
Feature Sets Tasks In Progress Done Urgent Queue
Kanban is great for managing a large queue of defects, especially if it’s easy to release the product after each fix. But kanban is not easy to implement for many teams.
In order to stabilize the amount of work in progress, you have to become accomplished at defining MMFs of roughly the same size. But, many product owners, product managers, and product development teams are not good at estimating the relative size of feature sets. If you’re working on a new, never-been-done-before product, you have never worked in timeboxes, and the team has never tried to estimate sepa- rating size from duration, then you may have trouble with kanban. In addition, if your team has few generalists and many specialists, it will be difficult to work on just one MMF at one time.
To fix the queue size for a project, the team needs to create small MMFs of similar size. To fix the queue size for a portfolio, the team needs to be able to work on any product, and the people ranking the requirements need to define MMFs of relatively small size. If your organization can’t do that, you won’t be able to stabilize the work queue.