Improving Software Dev and Del

I just finished listening to Dave Farley and Jez Humble looking back on their continuous delivery book after writing it more than a decade ago  https://lnkd.in/exk_v8EU (highly recommended).  Two observations really stood out for me.  First, is that after all these years they wouldn’t really change much except for adding a little more focus on security.  Their approaches have been proven out through experiences in a broad range of applications and confirmed with research.  Second, when recommending these “proven” approaches to others, they are still seeing lots of resistance.  

The challenge is less about finding better ways of working and more about getting people to invest in improvements and embrace new ways of working. Overcoming this resistance to change requires learning from organizational change management experts like Jonah Berger .  He points out that the harder you push for people to do something the harder they resist. Instead of pushing harder we should instead focus on overcoming their barriers to change.

One of these things that I have found works for me is moving away from telling people to do things like CI, CD, TDD, etc. where they have preconceived notions about what that means and prepared arguments for why it won’t work. Instead, I have moved to trying to explain the basic principles of improving software development and delivery in very simple common-sense ways that are harder to refute. Teaching people how to make their process visible and then letting them pick the improvement they believe will help their organization the most makes them more likely to invest in the improvements and embrace the new ways of working.  

Here is my best attempt to explain it simply.  Hopefully you find it helpful.

Software development and delivery contains two different types of activities that require different approaches for improving.  The first are very creative processes of working with the business to create software that solves problems or adds value that are unique each time.  The second are tasks like testing, creating environments, and deploying code that are repetitive processes.

One of the biggest changes that has helped the creative process of providing solutions to business problems is shifting to building in quality.  Manufacturing learned a long time ago that the only way to be successful was to build in quality. They did this by controlling the process because the process was creating the product. Software is different in that it is a person working with the business to create new solutions each time.  Instead of controlling the process we need to work to give that person the best possible feedback on the intended and unintended consequences of their changes and how it works with the rest of the software.  The quicker we can provide this feedback the more help it is to the developer in terms of improving and limiting work going down the wrong path.  The slower this feedback is due to batching up changes for testing or by isolating different batches of changes from each other with things like feature branches the harder it is for developers to improve.

Repetitive tasks are different.  Like in manufacturing, they can be automated to reduce costs and ensure consistency.  Then they can be continually improved over time like any automated process.  This automation provides several benefits.  First, it reduces the cost of manually doing the same thing repeatedly. Second, it provides consistency that keeps the developers from being distracted by problems that were not associated with their code changes.  Third, it enables working in small batch sizes that are much easier to debug and triage.  Automating and improving these repetitive tasks reduces costly manual work and frees up more capacity for creating value for the business. Any manual repetitive work in your software development and delivery processes should be seen as waste that could be eliminated to free up capacity to create more business value.

The goal then is not to tell people what to do. Instead provide them with a very simple common-sense approach for thinking about their software development and delivery processes and then provide them with approaches to help make their processes visible to everyone. This enables them to shift from resisting what you are telling them to do.  They are then able to come together to create their own ideas for improving feedback to developers and reducing the waste in repetitive work.