Yes you KANBAN! A recipe for success with Kanban flavour

One of the most important books about software development I’ve ever read is “Kanban” by David J. Andreson. The book gives a brief introduction, based on a few gripping case studies, to Kanban as an agile software development methodology.

One of the chapters that has especially caught my attention focuses on “A Recipe of Success”. The recipe is a stack of 6 rules.

Rules should be implemented in the particular order to achieve success. It is something I have already mentioned in my previous post about customer experience. You have to start from fundamentals to build up trust in the organisation and then try to encourage change in other areas.

Focus on quality

It’s the best way to gain trust. You can use number of different techniques to increase quality of your software: test driven development, code reviews, using frameworks. Implementing well written plugins and outsourcing part of application to external services to avoid writing code on your own is also a good way to improve quality. As some smart person has said - the best line of code is the one you don’t have to write yourself.

Reduce work in progress

Limiting work-in-progress is one of the main ideas behind Kanban. It implies pull system of workflow. “There is causation between quantity of work-in-progress and average lead time, and the relationship is linear”.

Deliver often

Delivering often pushes you to work on reducing delivery costs. Automated 1-click deployment, or continuous deployment are proven to be the right way to go for web development. It also has a great impact on your organisation culture. Frequent releases build trust.

Balance demand against throughput

New requirements are coming in only if existing work is delivered.

Prioritise

Having clear priorities makes everyone’s life easier.

Attack sources of variability to improve predictability

This one is especially difficult to set up. It requires high maturity of organisation. The idea is to try not to break a cycle with any unscheduled, time consuming requirements both from business and development teams. It’s very difficult to reduce all kinds of variability but even reducing some of them encourages better product development culture across the organisation.