Category Archives: Kanban

The Kanban recipe to success

Recently I’ve read the illuminating book “Kanban” of David J. Anderson.
One of the chapter that impressed me the most is “A Recipe for Success”.
I’ve been working for the past few years in Agile teams and individuating ways of improving our work and simplifying the development process, was not an easy and immediate exercise. Retrospectives would help, but it would require quite few meetings, and therefore months, before being able to appreciate improvements.

In “A Recipe for Success” David introduce six ingredients that will definitely improve team performance. These ingredients are listed from the easiest to be applied to the most complex one.

They are:

  • Focus on Quality
  • Reduce Work-in-progress
  • Deliver Often
  • Balance Demand against Throughput
  • Prioritize
  • Attack Sources of Variability to Improve Predictability

Focus on Quality is the simplest one because does not require any agreement or cooperation with individuals external to the team, but is more a technical exercise. Putting in place a Continuous Integration system, introducing peer review and involve QA Engineers in the software life-cycle, will increase the overall quality with a relatively small effort. This should be your team’s first investment.

Nobody likes context switch and reducing Work-in-progress will allow individuals to keep the focus on a single task as well as stabilize the lead time. Introducing or reducing the wip will allow team member to deliver more doing less.
Introducing wip has to be agreed with upstream (PM) and downstream stakeholders (PM / Ops), so some level of coordination is required.

Agile is all about communication and feedback, deliver often can be read into the more effective “fail fast”. Fail is not a problem, it can happen, but the quicker it happens, the better.
Here again some coordination is required and it might also have an impact on costs (release coordination cost). The easier is to release software to production environment the better.

Demand and Throughput. They are related to the WIP and bottlenecks and it takes a while to get those bad boys right, but once that all the bottlenecks have been individuated and solved, the team should be able to work at a steady pace. This is a pretty complex subject and I will hopefully write something in the future.

Prioritize. Ask your Product Owner, “if you could deploy in production a feature / bug / improvement just with a snap of the fingers, what would it be?” Then that’s the item you should be work on.

Attack Source of Variability to Improve Predictability. Predictability is the key for building trust with Product Owners and Manager.
Superficial stories breakdown, cards blocked because of dependencies to resources external to the team, are all elements that affect predictability. Decent Throughput can still be maintained incrementing the wip (at the cost of stressing more the team!) but it would also increase the lead time. Tackling sources of variability is not a trivial exercise and requires a non banal team maturity. Attempting to resolve them should only be considered last, when all the other steps have already been taken.

The Bright Side of Java & Linux

Yet another Java blog


Bringing empathy into knowledge workers life

%d bloggers like this: