Software-delivery process flow Version 2.0

As you can see from the following diagram, things have become very complicated for the ACME team. What was simple and elegant has become complex, convoluted, and highly inefficient. The number of steps and barriers has increased, making it extremely difficult to get software delivered. In fact, it's increasingly difficult to get anything done. The following figure gives you an overview of the ACME Version 2.0 software-delivery process:

If I'm honest, the process as depicted is actually missing some additional detail in relation to the change-management hoops that can add more complexity, effort, and pain. Let's add this detail and look again:

As you can see, things are far from ideal. What was efficient and effective is now the exact opposite. More importantly, the dialogue, quality of the communication, and trust between all of those involved in delivering changes is at best fragmented and pretty much non-existent at worst. What used to be a five-minute chat over a coffee is now a 20-page email thread, meetings, and Skype chats. The ex-ACME engineering team members are less like colleagues and more like entrenched combatants.

Not only is the process long-winded, but the chances of a single change getting all the way through the process without issue is very slim—most of the time, changes have to go around the loop a number of times before they can be classed as shippable; for example, a defect found within any part of the process may push the change all the way back to the beginning of the process.

I mention dialogue, quality of the communication, and trust for a very specific reason—most of the things you read about and hear in relation to CD and DevOps seem to imply that some new tooling and best-of-breed architectural approaches will give you what you need. While this can help, it can also massively hinder—especially when trying to bring these changes on board whilst a business is going through organizational changes and/or growth. In the ACME example, too much was changing too quickly for everyone to understand what was going on and where the journey would end. This inevitably lead to human nature kicking in and people building up barriers and silos to add some stability within the chaos.

If you were to take all of this into account, from an outsider's perspective, the process(es) ACME systems uses to deliver software is now, for all intents and purposes, broken.

OK, so this may be a little over the top, but it just goes to highlight how having a relative chasm between those involved in the delivery of changes—especially the R&D team members (who are tasked with delivering much-needed changes and features) and the operations team members (who are tasked with supporting the live environment into which the changes will be applied)—can completely derail things.