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
Here’s an example of an XP Value stream
- A customer comes to the team with a problem they want solving, and collaboratively they write a set of User Stories
- 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)
- The team then pick the first of those User Stories, and plans how they will build it.
- They build a User Story (using good engineering practices)
- 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.
- 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.
- 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
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
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 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
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.
[…] XP As A Kanban System (Karl Scotland) […]
We’re pretty much doing this on our team. Working pretty well so far.
Could we not remove the “Kanban” and simply say that understanding a process / approach / methodology as a system helps us think about how to improve it?
Karl, I think this is true. For a long time I’ve recommended swarming on stories, and found this to be a more effective practice than merely pairing. Of course, the same effect may be achieved by slicing the story into multiple thin ones and have a pair take each.
In any event, I think that Kanban and Agile are just different view and different emphasis on the same basic stuff. It’s all good.
@Jason: I think the reason to mention Kanban is that I see a lot of teams fail to make the leap to the minimal-WIP process that he describes here.
Especially with iteration lengths above 1 week, too many teams do Scrum or XP in a mini-waterfall way, which causes a lot of pain and waste. Mini-waterfall is not a terrible way to go if you’re on 6-month cycles and just starting with an Agile approach. But it’s possible to do much better.
The best teams I see now are on one-week planning cycles, but they release every time a story is complete, which is as often as every few hours. That’s even more extreme than Extreme Programming, but if you use the Lean/Kanban analytical framework, it’s something you can arrive at very naturally.
Hi Karl,
Great description! It is very close to the process I saw our team evolve to after introducing and incorporating kanban concepts. A couple of key changes that jump out at this moment that occurred were related to:
1) “swarming” on stories, rather than only one pair per story, became the norm with multiple pairs on a story and focusing on WIP first whenever possible before pulling a new one which helped visualize too any bottlenecks immediately;
2) Decoupling intervals for planning/prioritizing, reviewing, releasing, and retrospectives. Planning/prioritizing went to more JIT as needed and not on fixed 2-week intervals. We continued to conduct “reveals/reviews” on a 2-week interval but these were more ceremonial to share information with broader business stakeholders. Before any such “reveal”, stories had already been reviewed again JIT with product owners/stakeholder as the last step to DONE-DONE. Releases to the field occurred as per business needs, not necessarily every 2 weeks or after each story was completed although the potential was there, but rather more often after one or more significant features were completed (“in the can”); and although we continued formal “retros” every 2 weeks, we’d “stop-the-line” and address a problem when/if it made sense too (impromptu “huddles” at any time of the day/week/iteration to address these we common).
There was one or two more when I started this, but…I’m shutting down after a long day.
Take care,
Frank
I appreciate the effort to bridge some of the current thinking in the community at a time when some people seem to want to divide up into “camps” and have a contest to split hairs.
The comments from Jason and William resonate with me. (I’m not putting “at” signs in front of their names because it’s a form of waste – the at-sign-equipped names aren’t clickable or usable in any other way, and they don’t aid in clear communication. No value. It’s also extra work – it takes two keystrokes. Muda.)
Karl, your example is very small scale. If there’s exactly one team and exactly one customer and the customer just walks over and asks the team to build functionality, it hardly matters what sort of process or framework they use. It seems to me the big issue these days is how to extend agile thinking across the enterprise, and how to scale the practices we’ve found to be so effective in the small. Lean tools give us a practical means to that end. XP is mainly a set of software engineering practices. Changing or adapting the process framework doesn’t eliminate the need for sound engineering practices. You seem to be interested in the question of time-boxed iterations specifically, rather than XP generally. Is that correct?
[…] where he adds The Fifth Primary Practice of Kanban. And his posts on Kanban, Flow, and Cadence and XP as a Kanban System are great, as […]
Nice article, it’s pretty much how I’ve always done xp. My only addition would be that in the first step, when a customer wants a feature they often want many and need some way to work out what really is most important to them. This often involves painfull tradeoffs (to avoid the story: I want it all and now). This was what the Xp planning game was about: the game came not from having fun, but how to balance a good mix of stories in an iteration that made the right tradeoffs (both in features and also in technical approach). The best way to drive this mix IMHO is still to do some form of estimation so that things have a “painfull” cost that makes you assess whether they are worthwhile or maybe aren’t specified correctly (a weak story that needs more work), or the wrong technical architecture is being used (a spike is required). I’m sure there is some Kanban’ish way of doing this, but I think it’s easy to ignore the utility of this step and simply call it waste. I’ve seen many an A-ha moment when teams forced to prioritize have come up with a new approach, or split a story in a much better way.
Dave, it’s true that scaling up is a bigger issue, but I think you forget how few small teams even now can actually ship stuff reliably, without crashing and burning. Process still matters for small teams.
I’d also argue that XP is more than just a set of software engineering practices (although it’s the only process that says anything about how to actually get code written), because it attempts to address (small-scale) organisational and even ethical issues.
S
There various ways to do PP. For example, in our team developers switch pairs daily. Usually it means that all team touch all stories during a week. We have no one story – one pair rule.
I don’t believe in swarming, since very often it is really hard to split work and keep it in sync between at least two pairs working on a single story (refactorings, design decisions, etc). Also do not forget merging. It sounds sweet, but in reality it may just hold development.
[…] at the Guardian. Some of the developers at my current client are also working this way, as are others in the industry. So, here are my suggestions for making this […]