XP As A Kanban System

During recent discussions with XP folks on the topic of Kanban, it occurred to me that based on my understanding, XP can be described in terms of a Kanban System for Software Development. This is an attempt to do that, on the basis that it might be useful in helping teams understand Kanban concepts. I have structured the description around the five primary practices of Kanban that I have previously blogged about.

1. Mapping the Value Stream

XP VSM

Here’s an example of an XP Value stream

  1. A customer comes to the team with a problem they want solving, and collaboratively they write a set of User Stories
  2. The team then holds an Iteration Planning meeting to prioritise which User Stories they believe they can deliver within the next iteration (which is 2 weeks in this example)
  3. The team then pick the first of those User Stories, and plans how they will build it.
  4. They build a User Story (using good engineering practices)
  5. When the team has something to show, they review progress with the customer. In this case, every 2 days on average. I assume that the team will be collaborating with the customer more often than that, but am not showing that level of feedback for simplicity. Reviewing a User Story may result in re-planning and re-building (iterating). Completing a User Story will trigger another User Story being planned and built.
  6. At the end of the Iteration, the customer accepts all the completed User Stories. At this point the User Stories are re-prioritised again and another set chosen for the next Iteration.
  7. At the end of the Iteration, the software may also be released, and more User Stories may be written.

In practice, the workflow is not this precise, but I think its a close enough approximation. For example, new User Stories could be written at any point.

2. Visualising the Value Stream

XP Visualisation

An XP teams may use a very simple visualisation such as the one above, which focuses on the Plan-Build-Review section of the Value Stream. The User Stories (yellow) chosen for an Iteration are initially not started. When they are planned, then tasks (grey) are added, and the tasks are working on until they are all done, and the User Story is Done.

3. Limiting Work in Progress

XP WIP

An XP team will limit work in progress by working in pairs, with each pair only working on a single User Story at a time until it is Done. Thus in the above example, a team of four developers limits work in progress to two User Stories by two pairs.

4. Establishing a Cadence

XP Cadence

XP teams have a very specific and synchronised cadence which is created by time-boxing the Iteration. Prioritisation, Reviews, Retrospection and Releases all occur at the same time interval, and User Stories are planned to be completed within that time interval.

5. Reducing the Kanban Tokens

image

An XP team is always striving to improve, usually by using retrospectives. As such, in the above example, they may reach a point where all four developers are able to work on the same User Story, and as a result complete it sooner.

Assuming that this description of an XP based Kanban System is not widely off the mark, I hope that it serves to communicate that XP and Kanban are not alternatives, but different and compatible ways of describing a process. Further, I have found that by understanding a process in terms of a Kanban System, it has helped my think about alternative ways of evolving that process in order to improve it. There is of course, more to XP than I have mentioned here, such as release planning, and the usual good engineering practices.

Kanban and Time-boxes

I had a brief exchange of tweets with Ron Jeffries, Keith Braithwaite and James Shore after the Miami Lean and Kanban Conference ended regarded Kanban and its compatibility with XP and time-boxes. Unfortunately I wasn’t able to follow up immediately, due to an urgent (and eventful) trip to South Beach 🙂 Rather than try and follow up late on twitter, I’ve decided to post my thoughts here to try and clarify my ideas.

The discussion started following a tweet about Kanban being easier to introduce than Scrum. This seemed to be a common theme at the conference, with several experience reports confirming what I have already written about whether Kanban is only suitable for mature teams. This led to the question of how much change (or not) a Kanban approach requires, which is where I jumped in.

A kanban approach introduces tools to visualise and measure queues and work in progress. While this is a change in process measurement, it doesn’t change the process itself. However, having highlighted the existence of queues and work in progress, it becomes easier for the process to be changed to specifically fix the issues highlighted. Thus a Kanban system sets a team up to begin continuous improvement. Time-boxing, used by XP and Scrum, is one way to manage queues and WIP, which is why they can be such effective processes, and why shorter time-boxes are becoming more popular. There are other ways of managing queues and work in progress, however, and thus Kanban is agnostic to time-boxing. This does not mean that XP is Kanban system however, because XP implicitly, rather than explicitly, manage the queues and work in progress.

Further benefits of time-boxing are the focus that they give, particularly given the finite or limited resources (i.e. people) within a team. Time-boxes give this focus not only by limiting the work-in progress, but also by setting the end of time-box as an SLA for when the work will be completed. Again, Kanban doesn’t lose these benefits, but provides for alternate means to limit work in progress and set SLAs.

To summarise, I believe that a Kanban approach is compatible with XP and Scrum in that it has a focus on managing queues and limiting work in progress, but also introduces alternate ways to achieve these goals which can be used alongside the XP and Scrum tools such as User Stories, TDD and Retrospectives.