Writing a book on software project management methodologies is not something to be taken lightly. One runs the risk of not satisfying anyone while trying to cater to the wishes of everyone. Even though the title and cover pages are 100% buzzword compliant, which is a warning sign by itself, Henrik Kniberg seems to have achieved a satisfying result in his book ‘Lean from the Trenches: Managing Large-Scale Projects with Kanban‘.
The good parts
The book is short. In 150 pages you cannot go into details and start theoretizing, and this is good because Kniberg promises to do one thing well and he delivers it: A case study of a 60-person software development team who used a mixture of Kanban, Agile (Scrum) and XP methodologies.
His explanations are generally clear and his definitons are sharp enough for practical purposes. He does not preach and never takes a ‘here is the absolute truth, use it as it is’ approach. He tells his team’s story and does not hide the parts that are still evolving.
The chapter ‘Agile and Lean in a Nutshell’ is one of the best chapters. In only 10 pages, this chapter succeeds to provide the reader with the essence of those methodologies. The subsection ‘One Day in Kanban Land’ is a very nice example of using simple visualizations and storytelling to explain a concept in very concrete terms.
The core ideas such as ‘why WIP (Work In Progress) should be limited’, ‘how to reduce the test automation backlog’, and ’cause effect diagrams’ are very well explained. I have also liked the chapter where the author justifies their use of physical Kanban boards and how they scaled those boards to 60 people.
The bad parts
The book is short. Do not expect to find detailed theoretical and historical discussions on the different methodologies mentioned. You will definitely need at least a few other books to fill in the gaps.
At that page count, it is probably normal that the author did not go into the direction of deeper analysis, and especially talk about the details of problems they have solved, as well as other challenges he and his team encountered. Nevertheless, I believe enriching the book in that direction would only prove to add more value to the book.
The photographs, screenshots, diagrams, and index could be better, in color and titled. In its current form, they help to form the impression that the book has been very much rushed into production. That may be fine in terms of lean book production, or Agile Book Writing, or using Kanban to write a book, but the readers deserve more than that when they hold a book in its final form. Moreover, simply dropping footnotes at the end of a page and not creating a short References chapter is annoying because it prevents you from easily skimming those resources.
As a case study of a successful, real-life software development project that utilized Lean, Agile and Kanban, this is a book with very valuable lessons. It will probably be more helpful for decision makers such as software team leads and/or software project managers. It is not the reference for any of the software methodologies, but it stands as a very good evidence describing the daily operations of a relatively large team.