Henrik Kniberg - Lean from the Trenches: Managing Large-Scale Projects with Kanban

We who give project advice are faced with a mighty temptation. The teams who engage us are looking for direction, hope, ideas, energy, and guidance (and sometimes someone to blame, but thats a different topic). We are called in because we have been in a variety of situations, some more functional and some less. We try to help our clients move toward more functional. However, we are often as baffled as they about what to do next.

The temptation I am referring to is the temptation to begin speaking beyond our experience, to meet the clients need for certainty by manufacturing a certainty we ourselves do not feel. Left untreated, this results in dogma, revealed by words like must, always, and everybody.

One beauty of this books story is its complete lack of dogma. It is a story. A story of a project that had real troubles and addressed them with a small set of easily understood practices. Applying those practices required wisdom, patience, and persistence, which is why you cant just copy the story to fix your project.

The other reason you cant just copy the story is because it isnt written as a general prescription. It is a particular team in a particular culture with a particular client. You are going to have to work to apply it to your situation, but thats good, because you are in any case going to have to work to encourage any change.

There are general principles at work here. Ive been fortunate enough to work with Henrik a bit, and he told me he really has only one trick: make all the important information visible in one place and then decide what to do together. If thats his only trick (and I have my doubts), its a good one.

Society has learned to distrust us for our big, complicated, and ultimately futile public software projects. This is the story of a public service project that managed to serve the public. What it takes to regain the publics trust is teamwork, transparency, and early and frequent releases. Oops, I just succumbed to that temptation I just warned you about. Youd better just read the story and learn your own lessons.

Many of us have heard about Lean software development, Kanban, and other trendy buzzwords. But what does this stuff actually look like in practice? And how does it scale to a 60-person project developing a really complex system?

I cant tell you how to do it, since every context is different. But I will tell you how weve been doing it (basically a Scrum-XP-Kanban hybrid), and maybe some of our solutions and lessons learned can be valuable in your context.

This book is primarily written for team leads, managers, coaches, and other change agents within software development organizations.

However, some parts will probably be useful to anyone interested in software development, Lean product development, or collaboration techniques in generalregardless of role or industry.

For those who want to comment, go to the books main page, and from there you can reach the forum and errata pages. I welcome your comments!

This book is divided in two parts, each subdivided into several short chapters.

Part I, How We Work, is a case study showing how Kanban and Lean principles were applied in a large project for the Swedish police. The first chapter describes what the project was about, and the subsequent chapters describe specific challenges (such as scaling), how we dealt with those challenges, and what we learned along the way.

Part II, A Closer Look at the Techniques, starts with a high-level introduction to Agile and Lean and then expands on some of the practices mentioned in Part I, such as cause-effect diagrams.

I suggest you read Part I end to end, since that is the heart of this book, and the chapters build upon each other. Then you can cherry-pick from Part II, since those chapters are independent.

If you are new to Agile or Lean, dont worry. This book is all about practice, not theory. Ill simply show you what weve been doing, and youll pick up most of the theory along the way.

If you prefer to start with a high-level overview of Agile and Lean and the associated methods Scrum, XP, and Kanban, then go ahead and jump to Chapter 17, .

I dont claim that our way of working is perfectly Lean. Lean is a direction, not a place. Its all about continuous improvement. Lean has no clear definition, but many of the practices that we apply are based on the principles of Lean product development that Mary Poppendieck, David Anderson, and Don Reinertsen teach. And these practices, by the way, happen to match Agile principles quite well on most counts.

Another thingyou will see this project from my perspective, a part-time coach during six months of this project. My goal is not to present a 100 percent complete picture; Ill just give you a general idea of what weve been doing and what weve learned so far.