Planning like in an amusement park

In Kanban one of the most important metric is the lead time - either the local lead time between two stations or the lead time for the whole system, measured from the moment a client demand is accepted until the moment of delivery to the customer.
This latter part is not to be mistaken with a potentially shippable product increment or the comletion of development. Delivery in this case is the delivery of something that fulfills the demand of the customer and is actually usable by the customer.
A more drastic point of view, that could be taken is the time from the acceptance of the demand until the actual usage.

Planning with lead times?

From the question I get it seems that up-front planning with a system controlled by Kanban seems rather difficult to the average outsider - after all there seems to be no upfront planning and the systems only is measured “after the fact”.

You need a stable system

But that is only half of the story. Once you have a decent system in place and collect metrics on the different levels of work you can quite accurately predict the mean time it takes for a certain work item from the beginning of a queue to delivery. Of course this only works if the system is sufficiently stable, having a predictable capacity and a reliable flow management.
Regarding the different levels of work: think e.g. ‘Stories and Tasks’ or ‘Features and Tasks’ or ‘Initiatives, Features and Use Cases’ or other models of different levels of abstraction for work items. Klaus Leopold’s work on the Kanban flight levels is a very good resource with regard to this and details the different aspects from portfolio level to implementations tasks even more.
If you have a stable system with know rates of arrival and throughput you can start to put up virtual “current wait time from here” tableaus. Just like in an amusement park.

CC-BY-SA Martin Lewison

How do you plan in an amusement park?

Now – if your tableaus are reliable – planning becomes kind of easy. How do you plan in an amusement-park? You look at the posted waiting time and decide if you really want to wait this long for this ride. If so you join the queue. If not you go somewhere else. You might come back to see if the queue has become shorter. But you can’t join two queues at the same time. At some rides there might be a fast lane for pre-approved tickets, but those are more expensive, slow down the regular queues and are limited in space. You might decide to leave a queue and go somewhere else as long as you have not actually entered the ride, but then you lose your spot.
Like all analogies this analogy is not a perfect match, but this kind of thinking actually helps a lot in planning when working in a flow based system.

till next time

  Michael Mahlberg

“We need the historical data” is a complete straw man - at least for tickting (e.g. Jira) and version control (e.g. Subversion)

People get attached to tools. That is not a bad thing. It only becomes a problem once we become biased and start to rationalize our attachment with questionable reasoning.

One of the straw man arguments I hear a lot lately is the access to historical data that would be “lost” if we changed the system. Strangely enough this argument is used for at least two very different things – ticketing systems and versioning systems.

People tell me that they would love to change to a system that supports the team in modeling the actual flow of the work, but they have to stick with (a centrally managed installation of) Jira because otherwise “they would loose all the historical data”. In a completely different context other people tell me that they can’t move from the version control system subversion to the much newer version control system git because they would “no longer be able to access the older revisions.”

Event though both discussion are from different contexts, they share some similarities:

• Read-only access for the historical data was – upon enquiry – absolutely sufficient
• The relevant data could easily be kept available with very little effort.
• People had no experience with the proposed “new” tools
• In both cases a boatload of support processes was dependent on the old tools

The real challenge turned out to be training the people in a proper way and decoupling the support processes from the tools.

So, if there is talk about the necessity to access the historical data as a way to discourage switching to new tools, you might want to reconsider what is keeping you from switching to tools that are more appropriate for todays challenges. Is it really the need for historical data?

This is the 21st century.
Storage has become cheap.
Hardware has become cheap.

If you want to keep your historical data accessible, just buy a box to do so. Way cheaper than any sophisticated migration strategy.

On the other hand new tools require new ways of working – and whether that is quite as easy is something completely different.

I don’t want to say that changing tools is easy, my point here is that keeping the historical data is a straw man reason for not moving forward.

till next time
  Michael Mahlberg