Case study: Agile with Continuous Delivery instead of SAFe

This case study is about a company that tried for several years to make the company more agile with the help of the Scaled Agile Framework (SAFe) - unfortunately without success. The breakthrough came when Continuous Delivery was used as a driver for the transformation.

Even though this was a pure software project, the knowledge gained here can also be applied in systems engineering.

On our own behalf: Please take part in our AI surveys on requirements management (it's quick): Survey 2 >> | Survey 1 >> | Results

The case study

The complete case study is available at InfoQ under the title Agile Rehab: Replacing Process Dogma with Engineering to Achieve True Agility to find. It was written by Bryan Finstera consultant who has worked a lot with continuous delivery in the area of security.

In the company in question, even after years of "agile transformation", things were done with the Scaled Agile Framework (SAFe) not better, but rather worse. Therefore, changes led to the introduction of Continuous Delivery (CD), which ultimately led to the breakthrough.

Bryan does not name the customer or the product. However, it is an internal enterprise software system that was created by merging a total of four legacy systems and consisted of around 25 million lines of code (without comments).

To call the architecture "spaghetti" would be a serious insult to pasta.

The main problem: speed

Bryan was able to quantify the problem frighteningly well before the introduction of CD:

• 12 months: The lead time for the provision of a new capability for the company
• 3-4 times per year: Delivery of new features
• 3 days: The minimum time for implementing a change, no matter how small (one line of code)

Being able to deliver on a daily basis improved business results and team morale. It's a more human way of working.

Bryan Finster

Architecture: Downscaling and decoupling

The system had to be refactored. To do this, the team used Domain Driven Design to unravel the business functions. The teams were also organized accordingly, in line with Conway's law.

In order to decouple the parts of the system, the teams began to introduce Contract Driven Development (CDD), which made the interfaces stable and reliable. This made the teams' release cycles independent of each other. This approach revolutionized development, both in the consuming and the providing team. When new features were introduced, the interface was defined and tested before the rest was implemented.

In 18 months to the first daily release with CD

It took 18 months before the first pilot project was able to carry out daily releases. But daily releases are absolutely essential for agile working: How can we claim to be agile if it takes two or more weeks to validate an idea? Continuous delivery is also an enabler for many other practices and things:

• Continuous Delivery forces the introduction of Continuous Integration (CI).
• CI in turn requires that verification (tests) are part of the release.
• For tests to be part of a release, they must be (automatically) tested during development.
• In order to be able to test at an early stage, the requirements must be precise.
• This in turn forced the team to understand the business requirements and relentlessly eliminate the ambiguities in the acceptance criteria.

Optimized for operation

All processes must be designed primarily for operation so as not to jeopardize it. Therefore, even in the event of operational problems, the processes remain in place and must not be circumvented. The pipeline delivers all changes deterministically and with all validations to ensure that an artifact is "publishable". A well-designed process with efficient testing ensures safe emergency corrections. Another important principle was that each component must be deliverable without integrating the entire system. End-to-end testing was replaced by faster and more accurate virtual services, allowing problems to be identified and fixed more quickly.

Code is better than processes

The team has found that code (in the form of automation) serves a similar purpose to processes, but is much more efficient.

If teams handle dependencies with code, then PI planning (program increment planning) is superfluous. PI plans are static, code is dynamic

Bryan Finster

Roadmaps are adjusted based on the results. Spending days on planning to manage dependencies with the process and synchronize teams means that each team delivers at the pace of the slowest team. Decoupling and decentralization liberate the teams: costs are reduced, development loops are shortened and employees are happier.

The importance of metrics

Measurement is essential to evaluate your own progress and to convince decision-makers. It is particularly important to be able to prove your own success when making management changes. Bryan is a burnt child in this respect, as he has been in situations where management had other ideas that he could not stop without metrics. The result: quality and morale deteriorated and good employees left the team.

Continuous delivery is also possible in systems engineering

Continuous delivery is also possible in the field of systems engineering, where software, mechanics and electronics come together in complex systems, albeit a good deal more difficult. More difficult, but not impossible. More than ten years ago Joe Justice pioneered Wikispeed, which he later implemented at Tesla, SpaceX and Mercedes.

Conclusion

In this case study, Bryan Finster impressively demonstrates that automation is an important enabler for agility. The techniques and best practices have long been known from software development, where companies such as gitHub publish up to a thousand releases a day. It's time to apply this more in systems engineering.