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