Henrik Kniberg

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.… (mais)

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.… (mais)

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.… (mais)