Monthly Archives: June 2010

Learning together: Kanban and the Twelve Principles of Agile Software

Posted on by

This post is a spin off from the recent Scrum/Kanban debate.  Not wanting to let a situation go to waste, it seems a good time to affirm shared values, which I do here via the Twelve Principles behind the Agile manifesto.  I’m grateful to Joshua Bloom for his excellent input.

Commentary on the twelve principles of agile software

Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.

Kanban: Check. We pull business value through the system, creating flow.  It should be recognized however that sometimes we create value by means other than delivering software (sometimes even by not delivering software!).  Furthermore, the act of improving the system generates value as it increases the capability of the wider organisation to generate value.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Kanban: Check. We actively limit work-in-progress (WIP), facilitating late prioritisation and minimising the impact of change on lead times.  We actively work to clarify the customer’s priorities so that the team can manage risk by properly sequencing work.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Kanban: Check. We make deliveries at intervals consistent with customer need and transaction cost.  We seek to minimise transactions costs attributable to the software development process, thereby making shorter delivery intervals economically optimal.  Highly advanced teams look towards continual deployment concepts to limit the inventory of complete yet not deployed software. We believe the best requirements come from software already depoyed being exercised by the customers/users. Achieving flow to the end-user generates higher value faster.

Business people and developers must work together daily throughout the project.

Kanban: Check. The development team and customer must learn together, in relation to both the problem domain and the delivery process.  The visual element of Kanban promotes transparency and creates triggers for customer interaction.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Kanban: Check. Build processes that respect individuals; empower them to learn and to improve the system.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Kanban: Check. Visualization and models allow face-to-face conversations to scale effectively. Limiting WIP prompts teams to have conversations DURING difficulties.

Working software is the primary measure of progress.

Kanban: Delivered business value is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Kanban:  We work within and share responsibility for the capability of our system; sustained long-run capability cannot be built at the short-term expense of the individual.

Continuous attention to technical excellence and good design enhances agility.

Kanban: Check.  And we look to increase capacity by identifying and reducing the failure demand that results from inattention to quality.

Simplicity – the art of maximizing the amount of work not done – is essential.

Kanban: Check.  Furthermore we actively manage work-in-progress, minimizing work not finished.

The best architectures, requirements, and designs emerge from self-organizing teams.

Kanban: Check, and process too. Leaders (inside and outside the team) must foster emergence, not squash it.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Kanban: Check. Continually even.

Conclusions

So there you have it, no fundamental conflict but a couple of clarifications and some changes of emphasis too.  It has to be said that these small differences do add up to a shift of mindset, but it is one that much of the Agile community has taken on board as a result of the increasing influence of Lean.

If I were to pick out a key thought it would be this:

The development team and customer must learn together, in relation to both the problem domain and the delivery process.

This lesson would be recognised by much of the Agile community I’m sure.

Book review: “Kanban”, by David J Anderson

Posted on by

A big thumbs up for @agilemanager‘s book!  If Don Reinersten’s “Principles of Product Development Flow” (which I raved about here) provides the foundations, this is the practical, experienced-filled go-to book.   It feels very authentic, full of relevant examples and managing to be both measured and positive at the same time.  It will be the definitive Kanban book for a long time to come I’m sure; I sincerely hope that it goes on to achieve the status of “Agile classic” too.

Key chapters for me:

Chapter 3, A recipe for success.  The recipe has been developed significantly since this blog post (which is still worth a read).  I’ve followed much of recipe myself (some of it pre-Kanban), and it rings true to my own experience.  But full credit to David – if there exists a more effective version of the recipe than his, I would very much like to see it!

Chapter 11, Establishing service-level agreements.  I had heard about this and the related concept of “classes of service” before but it’s all a lot clearer now since reading the book.  It’s a thought-provoking chapter but I had the nagging feeling that it was just a stepping stone to something else (a prioritisation and scheduling mechanism based on risk-adjusted cost of delay) and David kinda confirms this.  That’s not to play down the importance of this chapter though – it definitely adds real sophistication to the generally-accepted core of Kanban, and if a practical guide can lead on to new thinking, that’s a thoroughly good thing.

Chapter 14, Operations review.  This sounds mundane, but it illustrates how a single Kanban implementation can seed something much bigger right across a business unit, breaking out of the confines of IT.  A very timely read!  Taken with the surrounding chapters we have here as good a guide to scaling agile development as you’re likely to read, and it reaches much further than that.

The final few chapters (Part four, Making improvements) are also worth mentioning together.  They take us back to Kanban’s roots in TOC and Lean (particularly Lean product development à la Reinertsen) and the influence of Deming, all in the process of giving yet more great advice.  Nicely done!