My Must-Read List of Software Process Books

Recently I was asked to give a talk on Continuous Deployment. I guess I was expected to talk about the technical challenges involved in building, testing and deploying software. But to be honest, those challenges are a small and relatively trivial part of CD. So I decided to talk about what I call holistic continuous deployment.

To get the full benefits of continuous deployment I argue that you need to improve the performance of the entire business system. You need to:

• shorten and amplify feedback loops

• enable the environment for continual experimentation

• encourage taking risks and learning from failures.

In the presentation I went through why and how to change the way to plan, communicate, collaborate, learn and lead your whole business.

I’ve given the presentation now in few places and one of the things people always ask me is “where can I read more about the topic”? I read a lot and love giving book suggestions. But this is a difficult question because how I see it, I’m asked “how to do modern software development well?” Much of it has to do with what could be called DevOps. But that too has become a topic that encompasses everything under the sun, depending on who you ask from.

Regardless, here’s my attempt to list some of the books that have had the biggest impact on my thinking on software development methods and processes. I will also briefly explain why I’ve picked each book. The list is also in the order I would read the books.

As with many seemingly technical efforts, successful holistic continuous deployment is 20% technology and 80% people. Picking the wrong technology, tool or cloud provider is rarely the real reason for failure. You are much more likely to fail because of communication failures, lack of empathy, lack of alignment or cumbersome organization structure. So what my book suggestion list is missing is probably 7 books on psychology and human behaviour research. But I don’t feel qualified to give advice on those topics.

I hope you find new ideas and inspiration from these books, or the research required to back your gut feelings up like I did. And do let me know your own picks!

The Goal is written by the Israeli business management guru Eliyahu M. Goldratt. It is a fictional novel about a manager in charge of a troubled manufacturing operation. The book is used in management colleges to teach students about the importance of strategic capacity planning and constraint management.

Time Magazine listed the book as one of "The 25 Most Influential Business Management Books”. The book is a quick read but gives you plenty to think about.

The Theory of Constraints presented in the book is easier to apply in manufacturing than software development. However I find the idea and process of flow and hunting bottlenecks important concepts when working in organisations.

The Phoenix Project - Gene Kim, Kevin Behr, George Spafford

The Phoenix Project is a book directly based on Goldratt's “The Goal”. The fictional story is about an IT organisation and its struggles. For me the story is a bit anxiety inducing as it captures so vividly many typical pain points in large IT companies. What stuck with me forever, since I read the book, is the fact that most organisations have “key person problems”. Key person is that one and only guy who “knows this system” or the only guy who “can do this database maintenance”.

You should do everything you can to distribute information and avoid creating these key persons. But when you already have them, you should make sure you allow them to have slack (these people usually work at 120% capacity) and that they should focus more on teaching others than executing.

Beyond the Phoenix Project: The Origins and Evolution of DevOps - Gene Kim, John Willis

I think Beyond the Phoenix Project is only available as an audiobook. It’s a quite freely flowing discussion between the authors of the Phoenix Project on how the book was created. They share interesting bits and pieces of how they learned what they did, what motivated their writing and how they eventually ended up writing the DevOps Handbook.

Devops Handbook - Gene Kim, Jez Humble, Patrick Debois, John Willis, John Allspaw

By the time I read the DevOps Handbook, it had very little new to offer me. But at that time I had been developing software as my day job for more than 20 years. Even so, it is a well written and extremely well researched book. It deals with all the mandatory topics on and around DevOps and I would encourage you to read it even if you feel very familiar with the topic. Also, I would encourage reading “The Goal” and “Phoenix Project” before this book, not after.

Accelerate: The Science of Lean Software and DevOps - Nicole Forsgren, Jez Humble, Gene Kim

Many processes and methods applied in software development today are used solely because they were suggested by Martin Fowler or Kent Beck said it’s good in their respective blog. Bringing in some more scientific approach is very welcome and my last two books do just that. The State of DevOps report has now been published for 7 years. In their own words “The State of DevOps Report is the longest standing, most widely referenced and largest body of DevOps research on the planet.”

The “Accelerate” book takes a deep dive into how the report is researched, how it has evolved over the years, the results of the report and the statistical methods used and their justifications. In general it’s very nice to have research data to back up your arguments on why some practices should be considered in your organization.

The Principles of Product Development Flow: Second Generation Lean Product Development - by Donald G. Reinertsen

With this book I’m torn. It is probably the best book on software development processes I’ve ever read, but the format (splitting everything into principles) is a tedious choice and the book is a pretty lengthy read. Despite its shortcomings I very much encourage you to read the book. I think it contains an endless amount of little golden nuggets and probably warrants several rereads.

The book argues in a very pragmatic way that many of our typical project management and product development practices are broken or plain wrong. Then the book reaches out to other fields of science and pulls in the necessary research to prove its points. We get to read research from telecommunication networks, queuing theory, the military etc. The examples show how things we tend to do in projects have been proven unsuccessful in many other fields.