Know Your Roots- Agile Lessons from Waterfall
Our heritage and roots can influence how we view the world, others, and ourselves. The roots of Waterfall and Agile methodologies are no different and shape how we work. It is commonly believed that the Waterfall methodology started in the 1960s, and the term itself was coined by Winston W. Royce's 1970 paper, "Managing the Development of Large Software Systems.” Royce’s insights laid the foundation for project management in the software industry for over 50 years, and his paper laid out some of the basic philosophies of Agile.
It is widely accepted that Royce advocated and created the waterfall concept. However, a complete reading of Royce’s paper reveals his support for iterative development and foundational agile ideas. What’s more, his paper describes iterative and agile concepts as enhancements to traditional approaches. Simple project management is ideal for projects with clear, fixed objectives, but it can be inflexible with changing requirements and uncertainties that typically occur during projects. According to Royce, “the simpler method (waterfall) has never worked on extensive software development efforts, and the costs to recover far exceeds… iterative processes." In his 11-page presentation, only the first page describes waterfall, but it remains a milestone reference for the traditional approach over 50 years later.
Iteration
Online queries credit Royce with establishing the waterfall methodology as a linear, sequential design process that involves completing each project phase before moving on to the next. However, everything after page 1 describes the then-novel proposition of iterative development, with the caveat “the implementation … is risky and invites failure”. Preceding and succeeding steps feed information to the current work and create more manageable change processes as design and development progress. Royce adds the idea of iterative contact between phases constrained to each successive step. This phased/gated approach allows flexibility at each checkpoint rather than waterfalling the entire work effort and deciding whether to release or rework at the end. The progressive review and decision points allow for a relatively frequent "continue or terminate" discussion as the project matures. Unfortunately, iterations are rarely confined to successive steps, and testing can lead to additional requirements.
According to Royce, an important criterion of software development is delivering two versions of the deliverable. The first is an iteration of the final product, which is the second deliverable. “If the computer program in question is being developed for the first time, arrange it so that the version finally delivered to the customer for operational deployment is the second version. The first iteration is simply the entire process done in miniature, with a time scale relatively small with respect to the overall effort.” Prototyping and quickly delivering value have roots in the above statement. Requirements change when stakeholders can preview prototypes and give feedback early, and then the development team can focus on the "right" things at the "right" time.
Sometimes, checking your foundations and roots leads to self-discovery and new insights. It is interesting to investigate what is commonly and incorrectly cited as one of the origins of waterfall and realize it was Agile all along. Continuous improvement and review adds value when applied to, well, everything.
Every project and organization is unique. Hylaine’s Delivery Services Consultants are highly skilled and experienced in many project management disciplines and can drive your project, program, portfolio, or change to fruition.
By Ryan Fish, Principal Consultant- Delivery Services