Think “executable process visualization” instead of “task-board”

A lot of the boards I see in offices nowadays are called Kanban-boards, even though they are actually more task-boards. And while often that is okay there are some advantages that we’re missing out on when we settle for task-boards.

Why exactly do we do Kanban boards?

There is a multitude of reasons to introduce Kanban boards, but one of the main goals might still be to visualize the workflow. On the other hand visualizing the workflow can hardly be a means in itself. One of the ends the visualization can help to achieve is clarity. Clarity about what we’re really doing. Clarity about the state we’re in. Clarity about the state the work is in. The ‘last workflow you’ll ever need’ (todo-doing-done) doesn’t really provide much help towards this end.

Accept reality

Modeling the real workflow does help. While preparing a talk, a friend and colleague of mine, came up with what I think is a great metaphor. He called the Kanban board an ”executable process visualisation.”

And once we start to think about the board as an “executable process visualisation” this metaphor turns out to be quite helpful in detecting differences between our model and reality. Let’s assume we have some kind of daily standup and talk about the work items on the board. Now, as soon as we find we have to explain that the ticket (the work item’s representation) is still in the same place, but work has progressed to a different state, this is a strong indication that our model does not quite reflect reality. On the other hand, if we move our ticket, but the work item actually still is in the same state, this might indicate an overly complex model that needs to be simplified to reflect reality.

Talk about the way you work

The great thing about having an “executable process visualization” is that talking about the model becomes much closer to talking about the work and vice versa. “But I thought that would be the first thing to do” becomes a question of “In which column does it happen? Can we make that explicit?”

This way the visualization becomes a powerful tool to enable substantial discussions and continue evolving the way you work from there.

till next time
  Michael Mahlberg

It’s a pull system – not “work on whatever you like”

In some circles, the term “Pull-System” has become a synonym for “My boss doesn’t tell me what to do, I can decide myself.” For me this completely ignores the fact that the term refers to a system and it’s properties, not to the way people in that system can behave.

Let’s assume a simple workflow consisting of four states:

| Ordered | Design | Accept | Done |
|         |        |        |      |
|         |        |        |      |
|         |        |        |      |
|         |        |        |      |

When we push items into the system they will pile up in the state before the bottleneck in the system. This might look like this:

| Ordered | Design | Accept | Done |
|         |        |        |      |
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |        |  [ ] |
|         |  [ ]   |        |  [ ] |
|         |  [ ]   |        |  [ ] |
|         |  [ ]   |        |      |
|         |  [ ]   |        |      |

In this case “Accept” seems to be the bottleneck. So whatever you do the system will not be faster than the speed of the “Accept” column. No amount of “pushing” work into the system will make it faster. On the contrary - the more work piles up in the “Design” column, the longer it will take for new items to get through the system.

We don’t know yet how much work is completed, so lets make that visible by putting an “x” on completed items

| Ordered | Design | Accept | Done |
|         |        |        |      |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|         |  [x]   |        |  [ ] |
|         |  [x]   |        |  [ ] |
|         |  [x]   |        |      |
|         |  [x]   |        |      |

Looks like 5 items in the “Design” column are just waiting to be processed. (Items in the “Ordered” column are always done, in the example there is no doing in the “Ordered” column). Pushing another Item into this system will only increase the amount of work not done - like this:

| Ordered | Design | Accept | Done |
|         |        |        |      |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|  [x]    |  [x]   |        |      |
|         |  [x]   |        |      |

One simple way to convert this system to a pull system would be to limit the number of items per column - for example like this. (We’ll ignore how to come up with these numbers for the moment that would be the topic for another post)

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |
|         |        |        |      |
|         |        |        |      |

Having these limits on the columns, the system could never exceed the following situation – Non-withstanding the question whether the work items are done or not:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |        |  [ ] |
|         |        |        |  [ ] |
|         |        |        |  [ ] |
|         |        |        |  [ ] |

Filling this system with done work and moving excepted work into the next done column we might find the following situation

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [ ]   |  [x] |
|  [x]    |  [x]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

And even though it is not yet visible to the naked eye this system already is a pull system if we add the simple rule that as soon as there is less work in a column than allowed by the limit we fill the column up to that limit.

Step one:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [x] ---> [x] |
|  [x]    |  [x]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

Step two:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x] ---> Pull  |  [x] |
|  [x]    |  [x]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

Step three:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x] --->  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [ ]   |  [x] |
|  [x]    |  Pull  |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

Step four:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [ ]   |  [x] |
|  Pull   |  [ ]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

which leaves the system in the state where there is an open pull request to pull more orders from outside the system.

Looking at pull systems this way shows that the term "pull" does not imply that in each pull system individuals can randomly choose what they want to do next, but describes one of the properties of the system itself. The level of autonomy –and how much each person is able to work on the stuff they would like to work on– can also be a property of the system, but it is a different property.

Having "pull" brings numerous advantages: better predictability, a better balance between throughput and utilization, and a more sustainable workload.

till next time
  Michael Mahlberg

P.S.: Of course this topic is way more complicated than outlined here and the relationship between limiting WIP and pull is not quite as one-dimensional as pointed out by Donald Reinertsen himself on Twitter. There is also a nice write-up on the topic from FactoryPhysics when it comes to the more intricate details of this matter.

Nowadays it’s Backlog Management

Back when Agile started out, the focus of many people was on getting things done. Getting things done the right way: with test driven development, continuous integration, merciless refactoring etc., and getting the right things done (with things like the planning game, the system metaphor, user stories and more).

And actually, software development became a lot better in a number of instances. Back then it was mostly eXtreme Programming for me, later things moved towards Scrum – at least in Germany, but also in a lot of other places. Still, the focus was on getting things done. Just by looking at the onmipresent "Scrum in «n» Minutes" presentations or even at David Harveys’s old but still excellent discussion of what is missing in those pictures it is easily discernible that most of the effort is put into the part where things get done.

Apart from the slightly disturbing fact that all those "agile processes" are in stark contrast with the first value pair of the agile manifesto ("Individuals and interactions over processes and tools") there is something else that is slightly underrepresented nowadays. Those pictures always start with an existing (product) backlog. Where does it come from? Of course the ScrumGuide includes the practice of backlog refinement (or grooming prior to 2011), but there is very little guidance on how to actually come up with – and refine – the requirements in the first place.

Even though there are many great tools available – Story Mapping, Impact Mapping, Buy a Feature, the Kano Model, to name just a few – they usually don‘t get too much air-time when agile practices are discussed. So let’s change that. Let’s go back to the old ideas – from eXtreme Programming times – of including the customer in the work, or let’s move forward to the Kanban way of managing work and model the whole value stream of the knowledge work and find appropriate tools for each section. Especially for those sections that lie “left of the backlog”

till next time
  Michael Mahlberg

Can’t I multitask at least a little?

One of the questions that arises almost every time a new Kanban system comes to live is something like “But if I work on tasks in different stations (columns) then my personal WIP-limit has to be bigger than one, right?”

Well...

Let me answer this by a simple calculation:

Given the cold hard truth that multitasking actually means task-switching there is a very simple formula to calculate your effectiveness for the average task you are working on:

If n is the number of concurrent tasks, then each task is idling around (n-1)/n of the time.

If you work on one task at a time this formula yields zero. Because the task is never left neglected and you work on it all the time.

If you work on two tasks at a time, each of them is idling around 1/2 the time. On average.

If you work on three tasks at a time, each of them is idling around 2/3 of the time. On average.

If you work on eight tasks at a time, each of them is idling around 7/8 of the time. On average.

Or to put it in percentages

• 1 task: 100% active, 0% idle
• 2 tasks: 50% active, 50% idle
• 3 tasks: 33% active, 66% idle
• 8 tasks: 12,5% active, 87,5% idle

This means that a task that would take an hour on average will take 8 hours if you multitask 8 fold. On average. And that’s not even taking any costs into account for context switching!

So, yes can multitask a little, but –like magic– multitasking comes at a price. Be sure you are willing to pay it.

till next time
  Michael Mahlberg

The round table - or how to make remote meetings (more) fair

Don’t single people out

In my opinion the worst way to have a remote meeting (aka conference call) is to have a bunch of people sitting around a phone while one person is sitting somewhere else alone in front of the phone. Even though the “80% of communication is non-verbal” theory from 1972 is mostly misinterpreted, a large amount of communication is not in the words alone. So this dysfunctional teleconference scenario deprives the single person of all the nodding, pointing, smiling, looking at the mobile, doodling on a notepad etc. of the communication.

Even a singe camera on the side of the many and a display on the side of the one person makes it way more balanced.

Two way video isn’t a bad idea either.

Don’t use huge video conferencing rooms

In theory, it is a nice idea to have two rooms equipped with high quality video gear and really large screens, so that it almost seems as if people sit in only one room.
In the real world this doesn’t work most of the time. Foremost because the two video conferencing rooms very often are reduced to two laptops at the ends of two conference tables.

Level the playing field

Yes, we all know that in person meetings are better than remote meetings, but if we have to do them, why not ornanize them in a truly balanced manner with equal rights to all attendees?

We live in a time where bandwidth doesn’t seem to be a problem anymore in most areas. The average TV nowadays sports a resolution of 4K. Even most office displays are capable of HD or better. So why don’t we go the easy way and instead of congregating in locations where we skew the communication channels, just use state of the art video conferencing software that allows for a gallery view of a dozen or so participants from our workstations so that all the participants have the same environmental conditions?

But I don’t like to be on video

Why not?
What is really worse when you’re on video compared to a real live meeting?
Of course you can’t (or shouldn’t) be in front of the camera in pyjamas and you probably can’t play World of Warcraft while on the call, but then again: would you do that in a live meeting? And if the virtual meeting is not that important, then it’s probably a good idea to say so and find better ways to make use of the time for all parties concerned.

But our company policy doesn’t allow for it

Bummer.
But hey, the upside is that you just identified a really huge cultural problem, that you and your colleagues can work on.

till next time

  Michael Mahlberg

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

Finally, once we become agile, all the planning goes away, doesn’t it?

No, it does not.

To quote a few things

“Responding to change over following a plan” -- http://agilemanifesto.org

The manifesto does not say “don't plan!”

“In preparing for battle I have always found that plans are useless, but planning is indispensable.” - attributed to Dwight D. Eisenhower

The major difference between agile planning and old style planning is that agile planning doesn’t happen up front, but just in time.

In mathematics there is a concept of an inherent complexity of a term that remains constant. A friend of mine explained it to me many years ago, but I can’t find the “law” related to this topic on the net. The basic idea is that it is quite easy to make a formula more simple by –for example– introducing a formula sign for the integral, but the overall complexity of the term remains the same. Introducing the integral sign only moves the complexity to a different place.

What kind of planning

Something similar seems to be true for planning. Without having at least some kind of plan it is hard to keep a group of people marching in the same direction, so you have to plan at least a little bit. If you ever hiked in an area without roads and pathways you probably noticed that it is only possible to plan in detail for the stretch of the way that you can actually overlook, but without having an idea about your next major destination you might end up spending the night in the open without anything to eat or drink.
So there seem to be at least two kinds of planning going on. Whether you relate those two types of planning to ideas like release planning, iteration planning, and task planning or not is of course up to you. (Some people might also think about release planning, sprint planning 1, and sprint planning part 2. But please remember that not all agile is Scrum)

Now for the big question:

Who’s doing all this planning in agile?

Most of the time when adopting agile you get rid of the fact that other people plan your work. But the flipside is, that –most of the time– the whole team has to take on the responsibility for planning. All of them. So don’t think that getting rid of other people planning your work also means getting rid of planning itself. Agile is very much about common sense, but that doesn't make it easy. Inherently tough things stay tough.

So, what are your plans?

till next time
  Michael Mahlberg

Do we have a Definition of Ready (DoR) and Defintion of Done in Kanban?

Funny you should ask – this ties in nicely with the topic of explicit policies.

Here is a short answer regarding DoR and DoD

Conceptually speaking, every station in a workflow has either implicit or explicit entry and exit criteria. The notion of a DoR and a DoD (as they have become widespread in the Scrum community) is modeling exactly this: having explicit entry and exit criteria for a system with one station.

When modeling a system with Kanban, those definitions for ready and done really need to become part of the often mentioned explicit process policies.

An Example

Let’s take a look at a simple example.
Assuming we have two stations A and B –where work flows from A to B– we look at B first, honoring the principle that we work on Kanban boards starting at the point closest to the value generation: the customer facing side.

|    station A   |    station B     |
|  doing | done  |  doing  |  done  |
|        |       |         |        |
|       / \      |        / \       |
|      /   \     |       /   \      |
|     /DoR B\    |      /     \     |
|    (   ⊆   )   |     ( DoD B )    |
|     \DoD A/    |      \     /     |
|      \   /     |       \   /      |
|       \ /      |        \ /       |
|        |       |         |        |
|        |       |         |        |

In this scenario the “Definition of Ready” (the entry criteria) for station B has to be part of the “Definition of Done” for station A. Why? Well, the “Definition of Done” for station A is the DoD for the Doing column of station A. Once a work-item leaves the “Doing” column nothing should be done with it – after all it has left one Doing column and not yet entered another Doing column.

Therefore when B pulls an item it will – or at least should – be exactly in the state it was when it left the Doing column of station A. That being said, there may of course be additional rules governing the entrance to station B (e.g. if the item is part of a multi-part workflow).

For the topic under consideration “Do we have a DoR and DoD in Kanban?” the short answer would be “yes”.

Scaling up

In any life-size system, where we have more that two stations, multiple sets of entry and exit criteria make sense – one set per station (column). Whether we focus on the DoR or on the DoD first, is a matter of focus. Both approaches might be appropriate.

Taking this further, beyond A and B we get something like:

|    station A   |    station B     |   Station C    |…
|  doing | done  |  doing  |  done  |                |
|        |       |         |        |                |
|       / \      |        / \       |                |
|      /   \     |       /   \      |                |
|     /DoR B\    |      /DoR C\     |
|    (   ⊆   )   |     (   ⊆   )    |     . . .
|     \DoD A/    |      \DoD B/     |
|      \   /     |       \   /      |
|       \ /      |        \ /       |
|        |       |         |        |
|        |       |         |        |

From my experience, it is helpful to start thinking this through from the right hand side and consider the DoRs first. But then again life is complex and depending on your actual situation there may be other approaches that make sense.

Ceterum censeo: Of course we can model everything we have in a Scrum process with a Kanban system. Both operate at different levels and Kanban is meant to be able to model existing processes. The question whether you should move from one to the other is non-sensical by definition but conversely adding Kanban to Scrum actually makes a lot of sense.

Cheers
Michael

Todo – doing – done is not “Starting with what you do now”

A couple of weeks ago I had this discussion about the Kanban principle “Start with what you do now” and whether or not that is the same as the “todo - doing - done”-value stream we know from personal Kanban.

Thinking that the two are the same is actually a very common misunderstanding.
”Start with what you do” now has nothing to do with “todo - doing – done” and actually predates personal Kanban by a couple of years. Todo-doing-done is a simplified concept that Jim Benson introduced to use the Kanban Method on a personal level. In Kanban terminology those boards are referred to as "proto kanban" – systems that might evolve into kanban systems.

"Start with what you do now" refers to the big difference in the approach. While in approaches like XP, FDD, DSDM or Scrum, you implement a whole new process, the Kanban Method’s approach is to model what you do now. In the Kanban system.

By simply stating todo-doing-done one does not yet model the way the actual team works.
Since the general workflow "todo – doing – done" is always true, there is not yet the connection to the way your team has agreed to work and no way to discuss specific process policies.

Facilitating the evolution of this very general approach to a system that captures how your team wants to work, and building the peer-accountability that is necessary, is one of the challenges for everyone guiding or coaching evolutionary improvement processes.

till next time
  Michael Mahlberg

Going fast without a fast-lane or an expedite lane

Does an expedite lane make you faster? And if so, why not put everything in the expedite lane?
Well, for an expedite lane to work several things have come together – Work In Progress Limits (WIP-Limits) and explicit policies, just to name the two most important ones.

When should we implement a "fast-lane" and what does "fast-lane" or "expedite-lane" really mean?

People have started to use expedite lanes in Kanban-Systems quite a while ago to handle the fact that no rule is ever without exception. If a Kanban system’s WIP-Limits do not allow for any more work to be started, there occasionally can be exceptions to the rule – production issues, "boss-tickets" and the like. To avoid having individually negotiated policies per ticket (which would rather invalidate the whole "make process policies explicit" idea) one way is to have an open discussion about handling exceptions and the rules governing those exceptions. For example: an exception like "We allow one ticket at a time to exceed the WIP-Limit of the system, but it still counts as WIP for other tickets" would be expressed by having a separate lane for exactly this ticket. Obviously this only makes sense, once we have WIP-Limits (that’s what the word kanban in the term “Kanban System” refers to) in place.
("In place" means that the limits are not only written down, but actually honored.)

What should we do if there are no WIP limits (yet)?

So what to do if you don't have WIP-limits in place and still want to negotiate some kind of special treatment for some tickets? Let's assume we want to make tickets visible that are of a higher priority than others or that are in a volatile state because of environmental issues? (As it was in the case in question: Developers already started while the ticket is still in the discovery Kanban)

Clearly in this case an "expedite" lane would not really give the same leverage it would do on a Kanban board with WIP-limits. Still I would consider those tickets to be of a different class of service which could – depending on the maturity level of the system – call for a separate swim lane or just for a different color coding of those tickets.

The other idea that might be spurred is to use a special work item type to achieve the same result. From a practical point of view this would taint statistics and metrics since there is no different way of handling those tickets. Therefore it might actually harm the system and make its future evolution more difficult.

Most importantly I would explicitly mark those tickets blocked – with a dedicated blocker type – that have to wait while these high-priority tickets are handled. And I would run statistics on those blockers afterwards. And publish those statistics!

Without giving the false pretense of having a high maturity Kanban system with an expedite lane this approach allows for explicit negotiation of the policies for this class of service that can be changed and re-negotiated over time.

And you can always move forward to a real Kanban system (one that has WIP-Limits) later.

So, how are you going to speed up

The "definition of done" for life...

...would be a scary thing, wouldn’t it?

Yet people often ask me “When will we be done with the change?” or “When will our working agreements (sometimes also called processes) be finished?”

But that’s just the thing. In an ever changing world neither working agreements nor processes nor environments can ever be finished. In our lives we don’t try to get to the finish – I, for one, actively try to avoid that for as long as possible. Most of us just have a life. One that is well suited to whatever the environment throws at us.

For me the question is not “When will the change be over?” but “which change do we need right now?”.

till next time
  Michael Mahlberg

P.S. It’s not the finish it’s the journey. Or, to quote somebody else:

Life is not a journey to the grave with the intention of arriving safely in one pretty and well preserved piece, but to skid across the line broadside, thoroughly used up, worn out and loudly proclaiming -- WOW-- What a Ride!
~ Paraphrased after Bill McKenna, professional motorcycle racer

If you talk about "Moving from Scrum to Kanban" you have misunderstood at least one of them!

• Scrum is a process framework for product development. The Scrum Guide says so. And the Scrum Guide pretty much is the official definition of Scrum.
• Kanban is an approach to process control and improvement. David says so. And he is the one literally defined Kanban for knowledge work

Scrum is defined by a specific set of roles, events, artifacts and rules that can make up a software development process when the specifics for your given context are resolved and defined.

Kanban on the other hand, provides mechanisms for controlling your work and improving the way you work together with a set of principles and practices like visualization, limiting work in progress, managing flow making policies explicit and a couple more.

Kanban does not provide counterparts to the things Scrum provides – rather, it is a complementary approach to any product development approach.

You can easily build a Kanban system for any given Scrum implementation - most of the time you just have to model four or five states, identify one to three capacities and define the cadence for the input queue and the output queue. A very simple approach here is to define the

• Stations as "Backlog", "Selected", "Implementation", "Review" and "in production" (and make them visible)
• (bracket) capacity of "Selected" through "Review" := throughput of last iteration
• input cadence := output cadence := iteration size
• iteration size := your sprint size

Of course the real power of the Kanban approach only begins after this stage, when you start to improve the way you work together collaboratively. But that would be another post...

Most of the time the processes inspired by the Kanban approach end up with a much more flow-based solution than typical scrum processes, and that is what a lot of people seem to mean when they talk about their evolution.

But please don't talk about "moving from Scrum to Kanban" – that would be like saying "I don't use a car anymore, I now use a GPS" – and you wouldn't say that, would you?

till next time
  Michael Mahlberg

We don't use a “process” we have working agreements...

“Yeah, well, I had to work around the process to get this stuff done for the customer.”
Doesn't that sound familiar? And more often than not people on the same team nod in agreement and work on like nothing happened. And soon somebody else says “Yeah, well, I had to work around the process ...”

But how about “Yeah, well, I had to violate what I agreed to upon how we work together to get the stuff done for the customer?”
In my experience people tend to be more easily annoyed or even upset by this latter violation of trust. But even more importantly the likelihood that people will re-negotiate their working agreements is also significantly higher.

That's why I try to convince my clients not to talk about “the process” but rather about working agreements.

Enter Scrum and Kanban

Now this is where approaches like Scrum, XP, FDD, SDSM or Kanban, to name a few, can hugely differ. Take Kanban and Scrum for example.
While Scrum is a Process Framework with very strict roles (at least for the Product Owner and the Scrum Master) Kanban is an approach for process control and process improvement. In many Scrum implementations I have seen, people have to “work around” things from the book. When –to name an example– was the last time you saw a person acting as Product Owner really having the final say on priorities?

Kanban on the other hand explicitly requires that we “Make process policies explicit” (4th General Practice of Kanban) – I like to restate that as “make our working agreements explicit.”

And once we start negotiating these agreements we actually start to “Improve collaboratively, [and] evolve experimentally,” as the 6th General Practice of Kanban describes.

I suggest dropping the chase for the perfect process in favor of finding the best working agreements (aka process policies) for the current situation.

till next time
  Michael Mahlberg

P.S.: The "General Practices" used to be called "Core Properties", but since the Kanban Condensed Guide, "General Practices" seems to be canonical.

Addressing risk does not mean eliminating it

"If a project has no risks don't do it" - that's what Tom DeMarco and Timothy Lister state on the very first page of chapter one of "Waltzing with Bears", one of the best books written on risk management.

The last time I wrote about risk I focused mainly on the project level of things. Recent discussions led me to revisit thins topic within the context of the risks themselves.

Eliminating risks also takes away opportunities. Big time.

Depending on the source there are many different definitions of the term "risk." Mmost of the time it comes down to the severity of an unwanted outcome multiplied by the probability of that scenario. The names for “unwanted outcome” and “probability” differ from field to field, but the gist stays the same.
There are so many things one can do with risks.

• risks can be mitigated (seatbealts mitigate the risk of a crash)
• risks can be avoided (staying at home avoids the risk of a car crash)
• risks can be compensated (first aid at the scene of a crash compensates –a little bit– for the risk of the crash)
• risks can be reduced (distance sensors and assisted driving reduce the risk of a crash. So do speed limits)

Obviously (?) the option that avoids the risk is also the option that takes away the possibilities, the upside potential. You'd basically be going nowhere.

So when you look at your risk list and try to “eliminate them all” you might want think about other ways of addressing risk than just eliminating them altogether.

till next time
  Michael Mahlberg

The “Pay to Learn” phase of projects

We should try to avoid waste. (Really?)

Nobody wants to create something just so it can be thrown away. (Really?)

Since “all universal quantifiers are always wrong”, those statements are probably not the whole story.

Even in lean eliminating waste is not as high a priority as one might think

In new product development – and re-implementing things in a different environment is new product development as well – a lot of effort goes into determining what the product actually is. And how to best build it.

Therefore some efforts are not waste at all, even if their results never go into production. In manufacturing and construction this is obvious for things like molds or scaffolding, but the same is true in knowledge-work as well.

Sometimes it makes a lot of sense to build something that will be thrown away, just to learn the right way to do it. Or at least a good way to do it.

Let’s have a look at Twitter for example. Twitter initially was build in Ruby (Ruby on rails to be exact). After a while it was rebuilt using different tools and techniques. So “obviously” the original implementation had to be “thrown away” at that time.
Does that mean that they shouldn‘t have started with Ruby? On the contrary – they ran with it for a couple of years. And they learned what they wanted to do with it.

But there are other things that you might not need in the later stages of product development – like dummy implementations of surrounding systems, paper mock-ups of user interaction, simulated server-roundtrips and a gazzilion more – but all of those help you learn.

And this "pay-to-learn" phase (with the willingness to throw away stuff that no longer is needed) is what often differentiates a really good product from a mediocre one.

till next time
  Michael Mahlberg