There are two major philosophies concerning how to approach the planning and structuring of project management or life-cycles: The traditional and straight forward methodology and the more recently developed and dynamic methodology. This article will clarify some of the key differences between these methodologies, examine what circumstances are best suited for one versus the other and how these methodologies can be combined to offer the best of both paradigms in a hybrid fashion.
Traditional and Lucid
When employing the Waterfall methodology, a project is broken in to discrete stages that are meant to be completed individually before proceeding to the next, without returning to a previous stage: requirements (establishing the goal),design (planning the solution), implementation (coding or building), verification (testing), deployment (delivering the solution to the end user) and maintenance (patching of issues, updates, enhancements, etc.). This methodology is very document oriented; each stage has a resulting set of documents that can act as an input to the next stage, until deployment when the product is delivered.
This methodology benefits from clear organization by keeping the various stages separate, a simple method for planning and controlling the project life-cycle and accurate estimation of required work and expenses as long as the requirements aren’t subject to any unexpected changes. However, in the real world, stages can not be strictly compartmentalized, often running in parallel, overlapping at times or requiring iteration loops between stages. Additionally, a strict sequential approach is not always required, beneficial or even the most productive, for example unit testing can be performed during the implementation stage. Requirements can also change or increase as a project progresses requiring a complete restart of the entire process.
This methodology’s key characteristics are the strictly partitioned stages, a progressing process flow without repeating previous stages and pronounced highs and lows with regards to business interaction. This makes it well suited for cases where stake-holders or users have limited availability since their involvement and interaction is concentrated around the requirements gathering early on and the user testing towards the end of the project life-cycle. Design and development stages typically require no such interaction.
Iterative and Adaptable
The Agile methodology began by using the sport of rugby as a metaphor for cross functional, collaborative project teamwork, with the project being passed back and forth like the rugby ball between players in an effort to get across the try line (project completion). This is reflected in some of the terminology. Projects are organized into a story (the goal of the project), the backlog (a set of requirements for completing the story) and tasks (the backlog broken down into component parts). Development is iteration focused, building upon a limited initial release. In an effort to complete the story, the backlog and subsequent tasks are broken up into sprints.
A sprint is a set amount of time (usually between 1 to 4 weeks) with clearly defined goals. A scrum consists of a group of people that have been organized to handle that particular sprint. During sprint planning is when the story is presented to the end user along with the backlog, which they are asked to prioritize. The scrum then reviews the prioritized list and identifies which tasks can be accomplished in the current sprint. A scrum meeting occurs every day as a status check on progress, planning, and adjustments. At the end of a sprint, a sprint review is held as a demonstration to the end users, presenting what was tasks from the backlog were completed during the sprint. Finally, a sprint retrospective takes place as a debriefing, covering what worked, what didn’t worked, and then reviewing that backlog items weren’t completed. These are then used as the starting tasks for the next sprint.
This methodology is well suited for cases when time to market is a consideration, with a base product being delivered quickly and built on with successive releases. Sprints allows for adapting to evolving end user needs through frequent feed back. Unexpected changes or additional requirements can be added to the backlog and implemented in future sprints with ease rather than starting over. However, this obviously requires more frequent interaction with stake-holders and end users, necessitating greater availability from them to achieve significant progress in a sprint. This can be difficult if the end users are not centralized.
Can an Agile Waterfall Hybrid work?
Since both methodologies lend themselves, individually, to certain types of projects, what is the best approach for large projects with component projects fitting both? A hybrid of the two has been shown to work, but is not without it’s own unique challenges.
A simple and common example of an Agile Waterfall Hybrid reflects the software development origins of Agile as well as the manufacturing origins of Waterfall. Development of a modern device requires both hardware and software components. The hardware can be developed following stages, with the requirements stage forming the backlog and story for software development to proceed in sprints. At the various stage intervals for the hardware, specific backlog goals will also need to be completed.
Tracking dependencies required for a clear staged structure becomes difficult across the relative complexity of sprint iterations. Merging the two paradigms cleanly at a release point can also become difficult, however, the flexibility of running a shorter or longer sprint can easily conform to the more rigid staged structure.
Final thoughts
Agile is more dynamic, responsive to change, and cost efficient for projects where requirements may be added and adjusted. In a world where change is inevitable, it is easy to see why this methodology is growing in popularity. Waterfall has held a position a go to for project management for a very long time because it keeps things simple, makes it easy to estimate costs, and simply works. If your stake holders have unchanging requirements, low availability and a desire for a one-and-done final result, it is an obvious choice. Combining the two can certainly benefit from the best of both worlds as long as the challenges can be overcome and pitfalls avoided. In the end, the best methodology for a company or project can only be decided by skilled project leaders that understand both the scope of the project, and the nature of their team.
