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.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Balanced Software Development

Agile2009 provided me with 3 sources of ideas which all complemented each other, and which I think make an important point that I want to repeat.

Firstly, on the flight over, I read John Shook’s blog post about his work with Starbucks. In it, he responds to the suggestion that by advising Starbucks on using Lean methods, he is transforming them into a robotic fast food joint like McDonalds. That suggestion sounds similarly like the common claim that Kanban transforms software development back into a robotic process. The piece that stood out for me was this:

Toyota combined old IE Scientific Management principles and techniques with social dimensions appropriate for the modern world. Even workers who do “manual labor” with their hands are knowledge workers. Front-line employees become the scientists.
By redefining roles, Toyota changed the answer to the question of who is the scientist in scientific management.

In other words, Scientific Management is still relevant for knowledge work, when the workers are the scientists. That keeps the balance between the Process and the People.

Secondly, Alistair Cockburn talked about three pillars of Effective Software Development in the 21st Century in his Agile2009 keynote. The 3 pillars are:

  • Cooperative Game
  • Craft
  • Lean Processes

Again, this to me demonstrated the need for a balance between the People and Process focussed elements.

Finally, I attended Jon Dahl’s talk on Aristotle and the Art of Software Development. This focussed on the differing ethical philosophies of Kant, and Mill and Aristotle:

  • Kant looked at the Acts, known as Deontology. This can be equated to looking at Process.
  • Mill looked at the Effect, known as Utilitarianism. This can be equated to looking at Outcome.
  • Aristotle looked a the Actor, known as Virtue. This can be equated to looking at the Participant.

Chatting with Matt Wynne after the talk, we both had the same thought. While individuals will probably sway to one form of these philosophies, there is room for all of them, and again, a balance is good. I would even go so far as mapping the three philosophies on to Alistair’s three pillars.

  • Deontology is Lean Processes
  • Utilitarianism is Craft
  • Virtue is the Cooperative Game

In many of the recent discussion I have seen and been involved in on Lean and Agile, and Kanban in particular, it seems to me that most of the debate is because the various participants are talking from the perspective of one of these pillars or philosophies. We should remember that they are all important, and that achieving the right balance is what is going to help us be successful in delivering valuable software.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Reflections on #Agile2009

I’m just about recovered from Agile 2009, and about to disappear off the grid for a much needed break in the sun. Before I do so, I wanted to jot down my immediate reflections on the conference while they were still fresh.

The conversations in between sessions are always great at the Agile conferences, but this year, I think these conversations were the main highlights for me. I met lots of new people who I’d only previously known online, as well as re-acquainting myself with people who I usually only see once a year. My top 3 highlights were:

  1. Discussing team maturity and explicit and implicit Kanban WIP limits with Alistair Cockburn.
  2. Splitting hairs on the finer points of Lean (Kanban) and Theory of Constraints (Drum Buffer Rope) with Mike Cottmeyer (apparently it was a highlight for Mike as well)
  3. Debating all sorts of ideas around Kanban with Arlo Belshee and Bonnie Aumann – including drawing on beer mats and using beer glasses and other implements to aid visual representation.

As far as scheduled sessions went, Mary Poppendieck gave a good talk on Workflow and Scheduling in which she nicely transitioned from a time-boxed schedule to a kanban work-flow using a form of cumulative flow diagram. Jon Dahl also gave a thought provoking talk on Aristotle and the Art of Software Development, which for me tied in nicely with Alistair Cockburn’s keynote, and some other thoughts I’ve recently had. I’m planning on blogging more on both these topics more when I get back off holiday. See you then…

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Agile 2009 and Scan-Agile

I’m going to be at Agile 2009 next week in Chicago. I’m not presenting any sessions this year, but I’ll be hanging around the Kanban stand at the Freshers Fair, and probably spending some time in Open Jam to hopefully catch up with people in person while I have a chance.

I’m also really pleased to have been invited to speak at the Scan-Agile conference in Helsinki, where I’ll be talking about Five Steps to Kanban. Here’s the abstract.

A Kanban System for Software Development provides an alternative means of creating an Agile Development process using Lean Thinking. Creating a Kanban System is not as simple as adopting a previously defined process as a starting point. Instead, a team needs to come up a model of its own process which will form the basis for further continuous improvement. This talk will introduce 5 steps that a team can use to create their own Agile process using a Kanban System for Software Development.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Does A Kanban System Eschew Iteration

There has been some recent discussion on the blogoshpere and twitterverse about the relationship between Kanban Systems for Software Development and the concept of iteration. The often raised concern that a Kanban System is “Waterfall 2.0” came up again, along with the suggestion that a Lean perspective might view iteration as rework, and as a result be waste.

One of the conclusions was that both a Kanban and Time-boxed approach are independent of iteration. I like Jeff Patton’s description of iteration. Iteration is used to find or improve a single solution. Incrementing is used to build up additional solutions.

It is perfectly possibly with a time-boxed approach to define a product backlog based on already decided solutions, and then prioritise User Stories to incrementally build up the functionality for those solutions. I don’t think this is that uncommon. Similarly, a Kanban System could be used to only incrementally build up the functionality for pre-determined solutions.

Done well, both a time-boxing and Kanban approach will prioritise work to generate knowledge and feedback which will help discover or refine solutions. What is really being prioritised in this case is a problem, or an ROI Component (as the Real Options tribe like to call it). This is where I think a Kanban System can help by explicitly managing the work at both levels. The ROI Components, which I prefer to call Minimal Marketable Features, can be prioritised and limited as Work In Progress. The MMFs can then be expanded to candidate User Stories which can also be prioritised, managed and limited in order to iterate the MMF. Eventually, the User Stories will be collapsed back together to actually deliver the MMF as an increment.

Thus a Kanban System can explicitly visualise that MMFs are being delivered incrementally, and are being iterated using User Stories. While this same approach can be used with time-boxes, it will often be implicit.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Kanban, Flow and Cadence – Russian Translation

Aleksey Goncharenko, a Project Manager at Flexis Corporation, has translated my Kanban, Flow and Cadence post into Russian. If you can read Russian, you can find it here!

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Skills Matter Slides and Video Available

The slides from my Kanban, Flow and Cadence presentation at Skills Matter are now available for download, and the video of the session is also available for viewing.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Lean & Kanban Miami 2009 Videos Available

This is the announcement from David Anderson on his blog:

After some delay while we arranged for hosting, the videos from the Lean & Kanban 2009 conference in Miami are now available.

I need to thank InfoQ for making all of this happen. As a media sponsor, InfoQ intended to use these videos together with the presentation slides on their own site. However, the videographer didn’t follow their format instructions and the result was that they couldn’t use them. So after some editing and cleanup they donated them to the community – in this case the Lean Software & Systems Consortium.

As a sponsor of next year’s Lean Software & Systems Conference, Software Engineering Professionals (SEP) kindly offered to host this year’s videos.

View now!

In particular, I’d like to highlight the video of my Kanban, Flow and Cadence presentation.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Ratings Activated

I’ve just activated ratings on the blog. They can be found at the bottom of each post on their indivual permalink pages. If you have the time and energy, please find your favourite (or most hated) entries and rate them. Feedback is always good 🙂

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

What is Cadence?

Mark Stringer gave me some good feedback recently, that I clearly hadn’t described what I meant be Cadence at the recent miniSPA conference. In order to try and correct that, I thought I’d try and clarify with a blog post that it not simply variable length iterations.

The purpose of a cadence is to establish a reliable and dependable capability which demonstrates a predictable capacity. Cadence gives some confidence in the upcoming work when we are triggering rather than scheduling work.

Time-boxing is one specialised form of cadence. It’s like a metronome, giving a single tick. All the main process events are based around this single tick, as shown below where the dotted vertical lines represent the Sprint boundaries. In this example, the unit of work is a User Story, and User Stories should be small enough to be scheduled into a Sprint, and subsequently completed in the same Sprint. Stories in Progress are limited to two, as a good Scrum team might, but Stories don’t always fit exactly into a Sprint. Note also, that while releases can happen each Sprint, User Stories are only potentially shippable product increments.

Sprint

Kanban on the other hand has a cadence which is more like a drummer. The rhythm is more complex than the single tick of a metronome, and can be more varied, as shown below. In this example, the unit of work is a Minimal Marketable Feature, which while needing to be as small as possible, is not constrained be being required to fit into a schedule. Instead, an MMF is able to flow over a number of process events while it delivers some releasable value. Planning, reviewing, retrospection and releasing all still happen regularly, but they are de-coupled. They can happen independently, at differing rates, which may provide more freedom in creating a natural process which enables the team.

Kanban

A cadence is usually ‘harmonic’, in that there is a neat overlap between the different rhythms, as in this example. However, it does not have to be. A look at some definitions of cadence can show why. These are some favourites I picked off dictionary.com

  • In music, the ending of a phrase, perceived as a rhythmic or melodic articulation or a harmonic change or all of these; in a larger sense, a cadence may be a demarcation of a half-phrase, of a section of music, or of an entire movement
  • Music. A progression of chords moving to a harmonic close, point of rest, or sense of resolution.
  • The flow or rhythm of events, esp. the pattern in which something is experienced: the frenetic cadence of modern life.

Thus cadence is what gives a team a feeling of demarcation, progression, resolution or flow. A pattern which allows the team to know what they are doing and when it will be done. For very small, or mature teams, this cadence could by complex, arrhythmic or syncopated. However, it is enough to allow a team to make reliable commitments because recognising their cadence allows them to understand their capability or capacity.

VN:F [1.9.22_1171]
Rating: 3.0/5 (12 votes cast)