2022 is quickly coming to an end. I am looking back at my most profitable and most exhausting year of the 9.5 years as a solopreneur. I helped a 50-people organisation change how they develop software - by introducing Continuous Delivery. After strong resistance at the beginning, we got a Continuous Delivery pipeline up and running. Overcoming the resistance would have much less coercion and fighting, if I had known Derby’s 7 Rules for Positive Productive Change earlier in the project.
We reduced the average time for building the software and running the unit tests from 50 minutes to 10 minutes. The pipeline could handle 50 integrations to the main branch in an 8-hour workday. We made it mandatory for developers to cover every code change with tests. These two measures showed positive effects quickly. Broken builds and lengthy integrations were a thing of the past. The number of bugs came down significantly. I discuss these changes in my post Can We Use Trunk-Based Development for Legacy Software?
We identified the dependencies between the seven teams and classified them as “OK”, “slowing-down” or “blocking”. Negative dependencies between teams were reflected by negative dependencies between software components. This is Conway’s law in action. We followed the recommendations of the book Team Topologies and applied the reverse Conway manoeuvre.
We decoupled the teams and defined clean team APIs mirroring our target software architecture. It became clear that the organisation must inspect the team and software dependencies every three months and adapt them as needed. Repeating the inspect-and-adapt cycle leads to separable teams with single-threaded leadership, the upgrade of the two-pizza teams.
Applying the principles and practices of Continuous Delivery relentlessly leads to loosely coupled teams mirroring the loosely coupled architecture. Such teams do not need the high coordination efforts of SAFe, waste in agile lingo. As a process innovation, Continuous Delivery provides an order of magnitude more value to customers than SAFe. And, it does it faster, too. This is the topic of Deming’s essay The Need for Change.
Without the five books, I wouldn’t have been able to help my customer effectively with their transformation towards Continuous Delivery. I read all books cover to cover. They lie on my desk for quick lookup. I hope you find these books as valuable as I did.
You may be surprised that my list of favourite books doesn’t include any technical books, say, about C++, CMake, Yocto or Linux. I read these, too - at least partially. Understanding all the latest C++ features doesn’t improve your performance as a developer. But understanding how TDD, trunk-based development, continuous integration and all the other Continuous Delivery practices play together through positive feedback loops does. Big time!
I wish you a Merry Christmas and a Happy New Year. All the best, Burkhard 💜