The defense industry, with its multi-billion dollar projects and contracts and multi-year timelines, has customarily built large cyber-physical products using waterfall project management methods. However, as technology advances rapidly and as the threat space within which these products operate continues to evolve, using the waterfall method to build such products no longer works. An alternative to waterfall project management is needed to build, operate, and continually enhance large and complex digital products.
Here is a case study of how the US Air Force (USAF) is making the transition from waterfall to SAFe to build its future land based intercontinental land based ballistic missile system. It has important lessons for companies making the transition from waterfall or partial agile (water-scrum-fall) methods to using agile at scale and DevOps to build and operate large digital systems, using multiple teams from multiple companies.
Here is the link to the Scaled Agile Framework’s video on how USAF / Northrop Gruman is making the transition from waterfall to SAFe and DevSecOps, along with my commentary on the reasons to move from waterfall to doing agile at scale with SAFe..
Start with the why : In order to succeed with a new way of working it is essential to understand why it is important to embrace the new way of working.
Here are the reasons USAF and Northrop Grumman ( the prime contractor) embraced the scaled agile framework to develop it new missile system.These reasons are general enough that they can be applied to any company building large and complex digital products.
So, here are my reasons why you should transition from the waterfall method or a partial agile method (scrum-water-fall) to the scaled agile framework.
- You have delivery deadlines to meet : Most companies have to operate in conditions where deadlines for having a working product in operation are fixed, and the costs of missing deadlines are extremely high. In USAF’s case, if a new missile system wasn’t available to replace a rapidly aging existing system by a certain date, there would be gap in US’s deterrent capability. While the consequences of missing critical product delivery dates, for non military organizations, may not be that dire, they still have compelling reasons to meet product delivery deadlines. However, the waterfall method or a partial agile (water-scrum-fall) method , is notoriously unreliable and rightly associated with the watermelon metaphor – the project is green on the outside and red inside. So, this is my first reason why you should embrace the scaled agile framework – you have delivery deadlines to meet.
- Your digital products are constantly evolving : In USAF’s case, and in companies building long lasting digital and cyber-physical products, products need to evolve constantly. So, the waterfall project management method and partial agile method ( water-scrum- fall) which use temporary teams and use proxy success metrics such as scope, cost and time to build products, is especially unsuitable for building constantly evolving digital products. Companies that need to build constantly evolving digital products need to urgently move to the organizational model of the development value stream, just as USAF did. A development value stream , as defined by SAFe ” are the sequence of activities needed to convert a business hypothesis into a digitally enabled solution” 1. These long lasting development value streams consisting of teams of teams ( Agile release trains and solution trains in SAFe terms) would be building and supporting constantly evolving digital products, iteratively and incrementally, through the life of the product. And this is the second reason why you need to move to SAFe : you need to build a constantly evolving digital product and you need to know how to use the development value streams model to build it. SAFe provides that guidance.
- You need multiple teams from multiple companies to build your digital products: While USAF’s case of development involving 10,000+ individuals in hundreds of companies across the United states, may be an extreme example. However, building and operating a large digital product, involves multiple teams from multiple companies. Neither, waterfall method or a partial agile (water-scrum-fall) method, work in this context. What is needed is a method to scale agile product development across multiple teams and multiple companies. And SAFe, as corroborated by USAF’s use of SAFe to build its new missile system, is a trust worthy method for scaling agile product development. SAFe principle #7 ” Apply cadence , synchronize with cross domain planning ” 2 and practices (such joint planning at regular cadences, systems demos, etc.) based on it, provide the reliable means of managing product development involving multiple teams and multiple companies. So, here is the last reason for embracing the new way of working – doing scaled agile development with SAFe : you need to build a digital product using multiple teams from multiple companies.