I’m using Kanban since 2011 to organize my work. From everyday tasks to small software projects and big holiday trips I could leverage the power of a simple and hassle free approach to reduce my work in progress. With less work in progress one can concentrate on getting the work done and is not constantly rescheduling it as part of an unsuccessful attempt to do multi-tasking.
Even if Kanban is a success for me, I had the feeling that something is missing to adapt Kanban in a bigger software project. When people with different responsibilities work together there need to be some common rules on how the work should be done. Plain Kanban doesn’t answer this.
Meet Xanpan
Allan Kelly found the same problems in his work. Unhappy with the strictness of Scrum he crafted his own method called Xanpan, a combination of Kanban and Extreme Programming (XP). XP focus is on engineering practices to write good code and achieve a sustainable level of quality, while Kanban (or Scrum) covers the organisational aspects. Using the best of both makes Xanpan an interesting new player for organising software projects.
What I Like
Unplanned work exists and happens all the time. While Scrum denies this fact or forces you to stop the sprint, Xanpan expect you to go ahead with the current iteration. The unplanned work gets marked as such and is prioritized like all the planned work for the current iteration. Is it more important than what was planned before, then the new item gets on top of the stack and is picked next. In the retrospective at the end of the iteration you can review what was planned and what work appeared out of nowhere. Should the amount of unplanned work be a problem you can decide how you want to handle it differently in the next iteration.
Different stakeholders in a project have different timetables for planning. The developers care for the current iteration, while the business may be more concerned that a certain feature is ready at a specific date. Xanpan addresses this by using multiple horizons of planning:
- The plan for the current iteration is the most detailed. Here one cares on the tasks behind the feature requests, how long they take and in which order they should be processed.
- The quarterly plans help the business to know what they have to specify next and where they have to make decisions soon. Ballpark estimates are fine for this level and will be updated as soon as you split the feature into tasks.
- The roadmap is the big picture for the next 6-12 months and is more an idea than a concrete plan. Don’t bother with estimates and velocity on this level – there will be so much change till these features find their way in the quarterly plan that estimating is more or less a waste of time.
In Xanpan work is allowed to span multiple iterations. While one should make a task as small as possible, there are situations when the smallest useful task still is too big for the iteration. With this rule you are no longer forced to make useless tasks each in need of a special definition of done. Instead you can work on the task and get it done.
Documentation on Xanpan
Currently you can’t find much documentation on Xanpan. The book “Xanpan” from Allan Kelly is a good and thorough introduction in this method.
If you prefer less text you find on his webpage a list of talks and blog posts on the creation and usage of Xanpan.
Conclusion
Roll-your-own methods are often crafted to fit into a specific environment. While I believe there is enough flexibility in Xanpan to be used successfully elsewhere, I can’t prove it at the moment. Neither can I guarantee you that Xanpan will get traction nor that it will be a serious competitor to Scrum (in a few years).
All I can tell you is that Xanpan combines many interesting ideas and I’m looking forward to try them in the next bigger project. I will keep you posted as soon as I have news on Xanpan.