Leveraging DevOps in a 'water-SCRUM-fall' world
Water-scrum-fall is a term coined in 2011 by Dave West of Forr
However, the bigger obstacles are in the transition from development to operations. This starts off in the early stages of a project when operations is asked to sign off on still-fuzzy system requirements and environment nonfunctional requirements (NFRs) and continues when development produces a deliverable and then has to wait for operations to be ready to deploy. In an agile development setting, this is further exacerbated. Development now wants to produce integration builds at the end of every sprint, as often as daily in some cases. Development creates multiple builds and expects operations to be able to provide on-demand, ready-to-go test and deployment environments for each such build.
Agile development to the rescue
Agile development practices were designed to bring development and business closer by engaging the business throughout the development cycle and allowing them to change requirements mid-stream, as development produced deliverables at the end of every sprint. This addressed some of the waterfall-like interactions between the business and development. It did not do away with them altogether. Approvals from lines of business for budget, from EA, and so on remain very waterfall-ish in most enterprises.
The DevOps movement came about to address the waterfall-like characteristics of interaction between Development and Operations. Agile developers practicing what is known as continuous inte
In order to address the needs of the agile developers and the need to manage a significantly larger number of environments than they have ever had to, the DevOps movement has developed a set of principles. These principles have been outlined in a series of excellent blog posts by my IBM colleagues.
Here, I summarize three overarching key principles that I believe are the pillars of any DevOps effort.
Three key principles of DevOps:
Let’s look at these three principles in detail and examine how they can help address the challenges that come from living in a Water-SCRUM-fall world. In part two of this post, I will go into specific recommendations on implementing these practices:
1. Develop and test against a production-like system:
As developers churn out new features in their applications on a regular basis, these features need to be integrated with the work of other developers on the team and also the work of other teams. The work products of this development and integration effort then needs to be tested in order to verify that the integrated software functions and performs as desired. Developers run basic tests on their own code, and then QA runs rigorous tests on the integrated software.
As developers and QA turn the software over to Operations, it is not atypical for Operations to find that the software does not conform to the specs provided to Operations for the environment that it would run in. They might also find functional and performance issues not found by QA. This happens because developers and QA do not test on systems that have the same specs as the production systems. This ends up with operations becoming system testers and leaving a large unmitigated risk in the system until very late in the delivery cycle. This is what makes delivering to Operations a waterfall-like process.
To avoid this and keep the continuous delivery process continuous, DevOps principles advocate that developers and QA deploy and test the software against production-like systems. The delivering of the software to Operations should not be the first time the system is deployed to an environment with the same specs as the production system.
2. Deploy frequently:
After developers and QA have access to a production-like system, it makes sense to leverage it fully. This means deploying the software being developed to these systems regularly to validate its functionality and performance and even to release the software to production and hence end-users as often as possible.
Some organizations have taken this concept of continuous delivery to the extreme, where they deploy daily and even multiple times a day. This is not unheard of for comp
3. Continuously validate operational quality characteristics:
Performance testing has become a norm for QA organizations. Running these performance tests against the software running in production-like systems provides results on performance and stress tests that are extremely accurate. However, after the software is running in Operations, things can still go wrong. The software might not perform as designed in the complex user environment or for new usage patterns. Although Operations will monitor its systems and ensure they are performing as specified, they also need to make sure they are monitoring the software applications that have been deployed to ensure they are performing as desired. If they are not, the developers and QA can be notified and they can work on replicating the issues on their production-like systems to find and address the cause of the performance issues. This creates an end-to-end feedback loop all the way through Development, QA and Operations.
These three principles of DevOps result in a change in philosophy for IT organizations. They change how developers, QA, and operations teams interact, reducing the waterfall nature of their interactions, thereby addressing water-scrum-fall. They change how development and operations collaborate around defining system specification and other NFR and SLAs. Most importantly, they change the expectations that developers, QA, and operations staff have of each other, allowing them to function as one team with a common goal.
In part two of this post, I will go into specific practices that can be adopted to improve these interactions between Development and Operations.
Also see this author's related blog post: So, what is 'Water-SCRUM-fall'?
About the Author
Sanjeev is a 18 year veteran of the software industry. For the past 15+ years he has been with the Rational Brand, coming to IBM via the Rational acquisition. He is currently a Rational Specialty Architect in the Mid-Atlantic Business Unit in the United States. His current area of expertise includes Mobile, DevOps, Agile Transformation and Application Lifecycle Management. He has spoken at several international industry conferences, including IBM Innovate and written multiple internal and external articles. He blogs at