{ Category Archives }
kanban
Kanban simulation
This Petri net models the kind of 2-tier MMF->user story product development process that Karl Scotland described here or that I described here.
This model is a simplification of a real software development workflow. It lacks some of the buffering and backflows that you would see in the real thing. If you want to see it in action, I have a PNML file that simluates the left-hand side of this diagram. I used the PIPE2 editor, which does not support color or hierarchy, so that model is limited to a single feature kanban with no detailed story workflow. It’s still fun to watch, and gives you some sense of how planning can be implemented in a pull system using minimum marketable features, rolling wave planning, and staged delivery.
Perpetual multivote for pull scheduling
|
If we’re going to schedule one work item at a time, then we have to have a reliable method of picking the next item. Sometimes the work has a natural order and more-or-less picks itself. Other times, we have a backlog of things to choose from and have to make a decision. This is not so much a prioritization problem as it is a filtering problem. We don’t care about the 30th priority feature in the backlog. We only care about the 1st priority feature. That should make it more a matter of eliminating things we’re not going to do now, rather than sorting things that we may do someday.
The priority also has to be “always live.” In our system, development capacity can free up at any time. When it does, the next candidate should have been previously selected so that the team can get right to work. That means we’ll have to make frequent updates to the selection process. If we’re going to do this frequently, it has to be inexpensive. Consensus building is expensive. My goal is to do this with no estimates and no meetings. My first proposal was to create fixed-size priority buckets and make work items compete for space in those buckets until they rose to the top. I labeled this idea the “priority filter,” and I’ve been using it for a few months. After some discussion about it, I asked for a Digg-like or prediction-market-like scheme.
|
Why pull? Why kanban?
People with different skills have to work together to deliver product features. Don’t build features that nobody needs right now. Don’t write more specs than you can code. Don’t write more code than you can test. Don’t test more code than you can deploy.
–or–
My team builds a component. Your team builds a component. I use your component. Don’t build features that your clients (like me) are not asking for. Don’t accept my requests if you can’t build them now.
Pretty simple to describe in theory. Some subtlety in practice. A kanban is a tool, and like any tool, it is meant to solve a problem. I think kanban solves this problem more efficiently than the known alternatives.
Options have value. Options expire.
Real options are an enhancement to, or perhaps an explanation of, the priority filter concept for backlog management.
A kanban is used to make claims against the productive capacity of some resource. If I have a kanban, I can give it to you in exchange for an object or process of real value. The value of a kanban depends partly on time. The most relevant temporal data about a kanban are:
…from which we calculate lead time and cycle time. A regular kanban represents a commitment–a real claim against real resources. When a kanban is exchanged, it is with an expectation of certainty that the work order will be satisfied. |
Planning decisions, by contrast, involve uncertainty about work that we might perform in the future. Work requests placed at the end of a deep backlog do not represent a commitment to deliver. Pending work requests are always temporally contextual. They can only represent current understanding and intent, and the world will change before they enter production. The longer the backlog is, the greater the uncertainty about relative priorities and lead times.
Such uncertainty is not a problem as long as we are always able to determine a satisfactory answer for what to do next. You can’t utilize more capacity than you have, and adjustments to capacity have a lead time of their own. Your plans and priorities are sufficient as long as you always know what to do next. An efficient planning process is just barely sufficient to provide that information.
The priority filter is an attempt to define a planning process that directly represents the distribution of uncertainty of pending work requests. The work requests themselves are represented as kanban-like tokens. However, a kanban as we’ve described it really only works within the context of carefully controlled queues and processes. A kanban is a commitment, when what we really need is an option. Still, the kanban is a convenient representation for visual control, so what’s stopping us from defining a new kind of option kanban for planning purposes? Nothing!
Like a real kanban, we want to encode information about the scope and value of the request, but the temporal information we need will be different. I will argue that there is only one thing about time that we need to know about our option token: the expiration date.
Placing a token in one of our priority buffers amounts to buying an option to schedule the work for production. The price of the option is set by the capacity of the buffer. The expiration date is calculated from the purchase date and a duration that is also bound to the buffer. So, the priority 3 buffer might have a capacity of 8 and a duration of 30 days. When a new token is placed in the buffer, we calculate the expiration date and the token begins to age. Our priority 3 option gives us the right to bid for any higher-priority options that become available. Availability of a priority 2 option triggers a comparison of priority 3 tokens to select one for promotion. All of the p3 tokens are ageing, and any that are not exercised before their expiration date are cancelled. A cancelled option might return to the deep backlog, or it might disappear entirely. Age then becomes a first-class consideration for competition, where a nearly-expired token may be promoted over a higher-value token that is brand new.
In this way, we work our way up the priority ladder, incrementally investing as our certainty improves, until we finally earn the right to buy a real kanban that we can exchange for the real goods or services offered by our production system. It’s only when we can afford to buy a real kanban that desire becomes demand and the lead time clock begins. If we end up getting cancelled, it will likely be while it is still cheap to do so. We’re only out the cost of our options, which should have been much cheaper than the cost of a real kanban, which we only want to buy if we’re certain that it’s for something that we want.
