Royce’s contemporaries, evidently looking mainly at “Figrue 2”, coined the word “waterfall” to describe plan-driven, big-design-upfront, single-iteration software projects, and said to themselves, “Sounds good. We should do that.” Ironically, the newly popular notion of “waterfall” did not include Royce’s improvements, which was the whole point of the paper, and for years, many teams blithely implemented the flawed pattern Royce was trying to improve.
The manifesto outlined practices that many teams had already been following independently for over a decade, including Scrum, Extreme Programming, and the Apache Way. (All of these disciplines, and many others, predated the manifesto.) As Agile matured, and DevOps arose, the waterfall morphed into a pipeline.
And the pipeline evolved into loops and mobius strips.
The Four Stages of Agility
A theme underlying all of these models is a four-stage lifecycle. Different authors may start their descriptions in at different stages of the same general loop, and some may use the same label with different meanings, but the round remains the same.
Atlassian DevOps IBM DevOps Lifeycle Classic DevOps OODA PDCA Waterfall Model Plan Plan and Measure Plan Decide Plan Requirements, Analysis, and Design Build Develop and Test Code, Build, and Test Act Do Coding Deploy Release and Deploy Release and Deploy Observe Check Testing Operate Monitor and Optimize Operate and Monitor Orient Act Operations
Regardless of which stage one calls the beginning, we can all end up with code in production and ready for more. For example, the “Act” stage in OODA is equivalent to the ”Do” stage in PDCA, and to the “Coding” stage in the Waterfall Model.
Shifting Right
In the Waterfall days, the Plan stage often received the most attention, and project failures were often attributed to inadequate requirements. Today, focus has shifted to the Code stage. If you take a second look at the pipeline diagram, you’ll note that Plan and Operate are entirely out of view. The Commit: Production pipeline is really only about the Code stage, or, at most, Code and a rudimentary Deploy.
I think this skewed focus is why some organizations may struggle with Scrum. We use agile techniques for Code, but we may overlook, that to be successful, Code relies on Deploy, Operate, and Plan. Instead of right-sizing Plan to take place just prior to Build, sometimes we just skip Plan altogether. Moral: Build-centric shops have a fish-eye view of the development lifecycle, and they leave developers thrashing on the hook.
Circling Left
Notions like DevOps and Continuous Delivery are bringing Deploy under the Agile umbrella. We can also see that people are starting to recognize the importance of using the Operate stage to create a continuous feedback loop. Modern practices like field-testing multiple presentations (A/B testing), along with offerings like Google Analytics and New Relic, all contribute to using actual, real-life experience as an input to planning.
Just as more teams embraced unit testing in the last decade, over the next decade, more teams will be integrating instrumentation and analytics directly into software. In doing so, we can provide better feedback to the Plan stage, refine the work we do in the Code stage — and seal the loop.
Software as a service changes how we deliver software, and there is still much we can all do help the entire organization change with it – in a good way!
As an industry, we used to overemphasize planning, and now we seem to overemphasize building. To be truly effective, I think we need to accept that all four stages are equally important. No one stage is a silver bullet. The secret sauce is that we need to do each one of the things just as well as the other things. As Robert C. Martin (Uncle Bob) points out in the classic presentation “The Land The Scrum Forgot“, software is a craft, and we can’t sacrifice forethought for velocity. (Gotta love Uncle Bob!)
In your organization’s practice, do you recognize the equal importance of Plan, Build, Deploy and Operate? Or is one of the stages treated as more important?
Ted Husted is a Kaizen Squad developer on the Nimble AMS product crew. “We make the good changes that create a great product.”
More industry insights, delivered to your inbox. Sign up for our blog!
