I recently read "Kanban – Successful Evolutionary Change for Your Technology Company" by David Anderson.
Power of Focus
The most important takeaway is the power of focus.
I don't think the author quite stated it that way. He basically presented numerous examples and statistical evidence to show that limiting work in progress lead to a more effective and predictable outcome for software teams; especially those working on maintenance or lots of little projects for different systems.
It seems the more work you have on your plate that you are trying to simultaneously juggle the less efficient people and teams are.
Kanban essentially proves what other authors (i.e. "Your Brain At Work" and "The Power of Focus") have stated numerous ways. People are horrible at multi-tasking, distractions kill productivity and context switching in complex tasks is expensive (time and energy).
So focus on one (or a small few) things and get them done. Then move on to the next thing.
Kanban enforces this process on people and teams by limiting work in progress in each stage of the value stream.
Other Lessons
Once you limit work in progress, you will discover your bottlenecks. You may or may not want to remove bottlenecks because the slack time other people have can be used to work on other improvements; this is where you get the resourcing for continuous improvement. The only issue I see there is the person who may be the bottleneck doesn't get slack.
Remove unnecessary work and processes (waste). Seeing the process operate on a whiteboard with stickies makes everyone aware of where the problems are. If you don't/can't use a whiteboard approach (electronic) you will have to spend a little extra time ensuring understanding in order to enable improvements.
Build a high trust relationship with business and upstream/downstream teams. Deliver often (regular releases) and products with high quality. Over communicate and involve stakeholders in decisions.
There are lots of other good takeaways, especially for larger organizations and teams.
Comparing Agile
The author tried to show how you could use Kanban on top of Agile or in organizations that could not make the leap to Agile for whatever reason. He seemed to think it could deliver most of the results of Agile for projects without the steep price of entry. However, from what I read, the best use of Kanban is for software maintenance teams or software teams working on lots of smaller projects.
I think that Agile teams using short sprints and limiting the number of features/stories taken on by a developer (or pair) will experience most of the same benefits without using formal work in progress limitations. Update: Pairing is also potentially a powerful way to keep focussed when done right.
And of course, agile should also be about continuous improvement and sustainable development.
Conclusion
The book has a lot of good ideas and points but it is not light reading and somewhat repetitive.
The big takeaway is…
The author has proven statistically what we all sort of knew. If you want to be effective at getting things done; work on one thing at a time and finish it before moving on.
This extends way past Agile and Kanban software development and is good for anyone or any business.
