Henrik KnibergCritiques

This is a great book if you're already familiar with Kanban and want to read a practical application of it in a large setting. Since it is a case study, the book is descriptive rather than prescriptive, which is a strength. However, since it is a case study and not an exploration of different techniques, there are areas where I would have liked more discussion of alternatives than was provided. Overall, a valuable read if you are already interested in Kanban.

One of the more down to earth, real world looks at lean and agile that I've come across. In the first half of the book, Kniberg outlines how his team used lean/agile to implement a software system for the Swedish police. He describes how the process evolved, what worked, what didn't, and why. There is no preaching and minimal buzzwords. Everything is explained through practice, trial and error, and experience, including the parts they had not figured out how to solve. It's refreshing to see a book like this with a real world account instead of an attempt to market the agile or lean concepts.

The book contains photos and diagrams that help visualize the concepts. The second part of the book has "in a nutshell definitions" if a few concepts, including scrum and xp.

Some nice quotes from the book:

I don’t claim that our way of working is perfectly Lean. Lean is a direction, not a place. It’s all about continuous improvement.

The key to minimizing risk in large projects is to find a way to “slice the elephant,” that is, find a way to release the system in small increments instead of saving up for a big-bang release at the end.

The project board is probably the single most important communication artifact in the project. It provides a high-level picture of what is going on in the project and illustrates flow and bottlenecks in real time.

The speed of a project is largely determined by how well everyone understands what’s going on. If everyone knows where we are right now and where we’re going, it’s much easier for everyone to move in the same direction.

If people can agree on a goal that they believe in, this has an immensely positive effect on self-organization and collaboration. Conversely, if people don’t understand the goal or don’t believe the goal is achievable, they will unconsciously disassociate themselves from the business goal and focus on personal goals such as “have fun coding” or “just get my part of the work done and go home.”

One of the classes in our code base was getting way out of control and needed some significant refactoring, but there was some resistance to spending time on that. So, one of the team leads printed out the whole class and laid it across the conference table! It was more than 7 meters long (23 feet)!

Our process was discovered rather than designed.

The nice thing about gut feel is that it often is a leading indicator of a problem that’s about to occur, while hard metrics often show a problem only after it has occurred.

Perfection is a direction, not a place!

A great process isn’t designed; it is evolved. So, the important thing isn’t your process; the important thing is your process for improving your process.

This is not a theoretical book, but a case description of a single system development project, the now famous 'PUST' system for the Swedish police, that was developed between the autumn of 2009 and the summer of 2011. The book was written and published in the autumn of 2011. At the time the system was a great success that allowed the Swedish police to work more efficiently, developed on time and on budget, which is rare in public administration.

This could have been a detailed diary of events, giving a background to the bureaucratic tradition and evolution of technological tools in policework, comparing Sweden to other countries. That would have been great. But it isn't. The book only mentions briefly which methods were used in the project, but doesn't give any details on when and how, or what the objections or obstacles were. The English grammar would benefit from proofreading by a native speaker, but the prose is still not good.

The system is now famous because it was soon (after 2011) replaced by another, developed with non-agile methods based on the 'Siebel' platform, resulting in a late and over-budget project that delivered a slow and defunct system. This second system, known as 'PUST Siebel', was scrapped in the spring of 2014. Perhaps some day, someone will write a book that gives a wider perspective, describing both systems and the personal intrigues around the change. I'm looking forward to that.

Short, informal, and they could've used a copy editor, but you can hardly beat the price, and I did enjoy reading it.

This is a lightweight introduction to both kanban and scrum development methodologies in the form of a comparison/contrast essay that spells out the essential assumptions of each, plus a case study. The goal seems to be to give you a rough idea whether one, both, or neither is suitable to your situation, and to serve as an introduction to your own experimentation and further research.

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 the 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.

Conclusion

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.

My software friends are talking about Scrum, Agile, Pair Programming and I knew nothing about it. I have a friend who even suggested that Agile could be extended to general organizational design and even leadership!

I read Henrik Kniberg's book, Scrum and XP (Extreme Programming) from the Trenches, on his suggestion and, well, he's right!

Kniberg's book is a concise "how to" on how his company implements Agile in their software development business. It's chock full of great ideas and details that come only from those that have actually practiced something. As such, I gained a good insight into how Agile and Scrum work, and you will too.

What I want to explore more, however, is the idea that Agile can be applied as a model for leadership, or, more precisely, how can the practices of Agile be applied more broadly to knowledge workers? I think the best way to think about it to briefly recap the points of Agile and at every point where you see the word "product" think "culture." Let's see how that works.

1. The Agile process starts with describing stories about how the product should work. The focus is not on how things aren't working but how they should work. Process step 1: collect stories.

2. In preparation for the sprint planning meeting, have the product backlog (the list of stories about how we want our culture/product to be) in shipshape. This means being clear about the outcome including an defined "when done." This invokes the element of clarity and measurability. When we do workshops on changing culture this reminds me of the step where I ask, "...and how would we know...."

3. Have the sprint planning meeting with the team. Allow the team to determine the scope of what projects will be included in the upcoming sprint. Principle: give control, don't take control. Corollary: move authority to information, not information to authority.

4. Determine overall sprint goal prior to closing the planning meeting. This ensures the necessary supporting condition of clarity is in place.

5. Launch the team and get managers, coacher, owners, out of the way. Again, giving control to the people who know (the coders, testers, developers).

6. Always test the product with a demo before saying "done." This emphasis on actual products is very helpful, especially when changing business cultures where sometimes there is a tendency to think in terms of vague changes in mindset. Instead, we should focus on specific behavioral changes that we can observe and measure.

7. Conduct an assessment of how the Sprint went and measure team velocity. This would apply to following up on whether behavioral changes are sticking or not?

OK, well, that seems clear enough but when it came down to it, what was the leadership team actually working on -- the parallel to the code the developers were writing? Well, I think the code (sometimes I call it the DNA) for the company's culture is written in the policy documents that give authority for making decisions and detail how we will interact with each other. The cultural "coders" work on these policy documents in the same way the software developers work on the code.

This is a great little book that introduces Kanban ideas of those who are already committed to aspects of Scrum. If your team finds that it has too many uncompleted stories in your iterations, you should consider Kanban, which puts a limit on how many stories can be WIP at any one time. If the number of stories that are WIP goes below the limit, the team can put more members on those remaining tasks to finish them off. By this means, Kanban is self-regulating, depending on strict limits about the influx of stories and how many can be in process.

That's all in the first half -- the theory, with some great illustrations comparing Scrum and Kanban boards, and how they can be integrated.

The second part is a case study of an operations group that moved to Kanban with small multi-speciality teams, each with one point person to handle a specific internal customer's requests. It seems like a nice setup for addressing IT needs of far-flung parts of an organization.

The thing that keeps me from giving this a 5 is that it's only 104 pages and a bit lite. Another case study would be helpful.

Really liked this book. I already read Scrum and Xp from the trenches and I recommended it to a lot of colleagues who where starting Scrum with little experience. This book for me it the logical successor. It gave me very good insights in how to apply kanban in addition to scrum and xp techniques. The tone of this book is very clear, basic and simple. The ideas can be applied immediately in a professional environment. The book is coaching and never dogmatic.