Agile, Lean, Kanban, SCRUM, … . Will it ever stop? No! Frankly, change is good. However, change doesn’t mean that it’s good for you. In the last decade we’ve seen an increase in the number of “new” approaches to software development and each of these has the fanatics who claim that their approach is THE BEST approach to building software. What’s a practitioner to do? All we really want to do is create great software, and it seems that when we get into a rhythm, someone comes along to tell us how to to it better—and we often find things getting worse. Then we’re told that we’re doing it wrong and we need to bring in an expert to tell us how to do it right.
Ever since I worked for companies that have built software applications and tools, I’ve been amazed at the willingness of people to decide to do something because it’s a best practice. Well, let me say that I think best practice is code for: “We have a way of working and we want you to work that way too. This way of working worked for us, therefore it will work for you.” This is usually delivered by a consultant or salesperson who wants you to buy their services or product. (Full disclosure, I am a consultant at times, and I try to help people work better.)
The problem is that all of these best practices are usually stated as fact, and the context in which they are good choices are often left out. I continually see teams that decide to adopt a process or tool and fail miserably because that method or tool is not right for them. This can lead to another problem, rejecting all of the new way even though there are some good things that will help you work better. Most books on software development process tell you the “right” way of adopting a new process or tool, but they do so in a dogmatic way: “do this and this will happen.” There is a scarcity of books that focus on the experience of adopting and customizing new methods. Lean from the Trenches, by Henrik Kniberg. (Pragmatic Programmers, 2011) is a great stride forward in correcting this.
If you have been hiding for the last decade, you might not know what Agile and Lean methodologies are. If you haven’t been hiding, you’ve heard of them andy may have some idea what they mean. In order to get a clear description of them, start reading this book by going to chapter 17, Agile and Lean in a Nutshell. You’ll find everything you need to know about these two there. Then go back to chapter 1.
What makes this, in my opinion, a great book is that Kniberg describes what was done on a large project for the Swedish Police rather than talk about how to do things in a perfect world on a made up project. As you read the book, you’ll feel like you are getting helpful advice from an experienced practitioner who knows how to fit the process to the project rather than shoe-horning a project into a process. For each part of the project, you will see how a technique is implemented and, more importantly, why that particular technique or adaptation was chosen.
Kniberg covers all aspects of the project in the first part of the book. He describes the daily cycle and the practices that support them. Since they wanted to use a flow model, they adopted Kanban to their project. He describes how they scaled the Kanban boards and how they used the techniques and tools to keep on focus to the main goal of delivering value to the customer. Planning, tracking, scheduling, managing requirements—they’re all in this book, but you get a specific instance of the overall process, not just the description. You see it in action and you get to listen in on the reflections of what worked and why.
If you’re interested in making your team work better, I suggest that you get this book before going out and hiring a consultant. You’ll see that a) it’s not much more than common sense, b) it’s a lot of work, and c) you’ll need to continually adapt. If you understand that, the rest is about the details and they’re unique to your situation.