Book Review: Lean from the Trenches

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.

Advertisement

Book Review: Team Geek by Brian W. Fitzpatrick and Ben Collins-Sussman

Yesterday I posted a lukewarm review about Driving Technical Change. I had high hopes for it and it just didn’t resonate with me. Today is a different story and a great way to start off the new year.

The bottom like for this book is: If you’re a software engineer who wants to do great things, enjoy your work, and work on a super team, read this book! I’ve been going through a lot of books on the subject of technical leadership, soft skills for engineers, creating great development teams, and so on. I’ve found a few that I thought were quite good and they either have become or will become part of the material for my software engineering, and other software engineering based courses. But this book trumps them all so far. If you only read one book in the next year on this topic, read this book.

The authors, Ben and Fitz, work at Google. They’ve held several positions with Google and other companies. They have been associated with the Subversion open source project for years. In short, they’re real engineers who know how to build and shop software. They also have a great insight into what it takes to build a great team, how to keep it together and growing, and how individuals can become a part of such teams.

Ben and Fitz have clearly experienced many of the same types of organizations and personalities that I’ve encountered over the course of my industrial career.When I read an early section, “The Contents of this Book are not Taught in School,” I was hooked. They say “At press time, we’re not aware of any curriculum that actually teaches you how to communicate and collaborate in a team or a company. Sure, most students are required to participate in a group project at some point in their academic career, but there’s a big difference between teaching someone how to successfully work with another person and throwing him into a situation of forced collaboration. Most students end up jaded by the experience.” Well, if you’ve been in one of my software engineering classes, you know this isn’t true. That’s exactly what I try to teach and pretty much the way I do it. These two and I share a similar mind set.

The book describes several types of people, and provides stories of how to get these different types working well with a team while maintaining a team’s culture. They have great stories that I was able to identify with. They don’t try to mold these stories into patterns. They just tell it like it is—and it works for me. I finished the book in a few hours of enjoyable reading.

Ben and Fitz have had the opportunity, it seems, to have been able to choose the types of teams they work with as well as the type of companies that they’ve been employed by. Not everyone has that luxury. What the authors think dysfunctional companies and organizations are simply the norm for a lot of folks. Don’t let that put you off if you’re in one of those type of organizations. You’ll find good advice on how to navigate through the bureaucracies and get things done.

If you are a software engineer—whether you’re starting out or have been at it for years—read this book if you want to be better at what you do and if you want to get more satisfaction from your job. If you don’t get anything out of it, you are either the perfect software engineer (which is about as real as the Easter Bunny) or you’re in the wrong profession and should probably look for something else to do. The time spent reading this book will yield many rewards.

Book Review: Driving Technical Change by Terrence Ryan

I’ve been going through several books lately on technical leadership. I’m interested in this for my software engineering course as well as a course on software project management that I’m putting together with a colleague. I was hoping that this book would have some real gems that I could use for material for these courses.

When I started the book, I was pretty excited. The table of contents started out with the right topics, in my opinion—Defining the Problem, Solve the Right Problem. But that was about the extend of the usefulness for my purposes. After this, the author goes into identifying various archetypes that one might encounter in software projects. These are the Uninformed, Herd, Cynic, Burned, Time Crunched, Boss, and Irrational. In order to give his choices credibility he applies the “Pattern” buzzword to them. I think he definitely identifies many of the characteristics that software developers encounter, but they just didn’t form a unified picture for me. It might be the fact that he keeps using adopting version control as one of his main examples. I don’t think this is a major issue today, but I could be wrong.

Ryan then goes into techniques for helping sway the opinions of the types he defined. The descriptions are not overly detailed, nor do they need to be. Scanning through the techniques to get a basic understanding of what they are and how to use them is worth the reader’s time. These will add to your toolbox of soft skills that you can use to be a more effective member of the team. These are not leadership techniques, but ones that any engineer can use to help introduce change to a project team or organization. The ones I found most relevant to my career are Gain Expertise (I just think of this as continuous learning), Demonstrate Your Technique, and Create Something Compelling.

The final section is a set of strategies one can adopt to systematically get changes adopted. After reading the first two sections, this should be almost self-evident to a smart reader.

If I were grading this book, I’d give it a B-. It’s somewhere in the middle of the pack for me as far s books that would help software engineers become leaders and effective team members. I think that even though the book is relatively short (213 pages), it could have been presented just as effectively as a series of a few blog posts—maybe that’s how it started.

The bottom line, from my viewpoint is: if you have some extra money for books on soft skills, it won’t be wasted on this book, but if your budget is more limited, look for a book that has more bang for the buck.