Sunday, December 31, 2017

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

Sunday, December 17, 2017

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.

Sunday, December 03, 2017

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