Authors: Eric Brechner; James Waletzky (contributes to a chapter)
The objective of Kanban is to add value to the product or service for the benefit of the customer at all times during the operation of the employees. It is therefore a sort of optimization of the efforts of the team members, for the benefit of basically all parties.
The author (Eric Bechner) writes from his experience as a pioneer of Kanban at Microsoft in the “Xbox engineering team”. From his experience he shows how it could work for other teams.
In the first chapter, the author indicates a hands-on way to convince management that Kanban is a way of managing that fits in well with the way of working in the present time. These arguments are packaged as a letter to management, which can be used almost instantaneously copy-paste, provided that adjustments are made for your organization.
In the second chapter “Kanban quick-start guide” you can get started with Kanban right away. The simple principles of Kanban are explained, so that the learning curve to get started with it is minimal. Of course, as with all management methods, sometimes problems need to be solved, such as bottlenecks or slow progress of things, or things that have an impact on the entire team. To address this, the most common problems are included in the “Troubleshooting” section where the reader can draw on the experience of the authors.
In chapter three, the reader learns Kanban’s management techniques to make time estimates, including how long the project will last. Concepts such as MVP (Minimum Viable Product), Number of tasks required to complete a product, “Task Completion Rate”, “Expected completion date”, “Current Task Estimate”, “Task Add Rate” are introduced … Unfortunately, formulas are always described textually and are not included in formula form, which would benefit some programming.
Chapters four and five respectively deal with the necessary adjustments when switching from the waterfall method or the Scrumm method to Kanban. Since it is generally human to resist change, each chapter at the end provides a “direct” Q&A section for answers to difficult questions from employees.
Chapter six deals with typical things for IT teams, such as “continuous integration”, “continuous publishing” and “continuous deployment” when developing components, apps and services. In addition, the dependence of a team on other teams can determine its own performance.
Chapter seven is about how you use Kanban in large organizations, with hundreds of engineers or more. In addition, interdependencies are even more determining factors for team collaboration.
Chapter eight is about sustained engineering. It has to do with the use of Kanban once the project has been delivered, but aftercare is still needed such as additional bug fixes or stabilization of the application.
The final chapter, chapter nine, looks at other sources and further: what can you improve once you have adopted Kanban? It tells about the use of Kanban in combination with Agile and Lean. It tells about the principles that Kanban uses such as visualization, minimization, “Little’s Law”, “Single Piece Flow”, and “Theory of constraints” and “Drum, Buffer Rope”. In this chapter the author gives tips for further literature on each topic for the reader that is interested in learning more about it.