Agile's ever-growing popularity has burst a dam of possibility, encouraging project managers to consider approaches beyond established techniques. The traditional waterfall approach doesn't always work for projects with changing business requirements or projects where tasks can't be constricted to one immutable phase. And despite all the buzz, agile isn't ideal for every project, either—a lesson learned by Tara Hamilton-Whitaker, digital development director at IPC Media, the U.K subsidiary of Time Inc.
Previously, the London, England-based magazine publisher “had a very disjointed way of delivering web-based application build projects and ongoing product development. Neither formal traditional waterfall nor agile working practices were effectively implemented across the board,” she explains. “A lack of formal process resulted in inefficiency, poor expectation management and a high degree of waste.”
To address these issues, Ms. Hamilton-Whitaker assessed the opportunities offered by both waterfall and agile delivery approaches.
“Agile sounded like a dream to me—delivering value sooner, and having teams work in a collaborative way and at a sustainable pace,” she says. “But it's a huge shift to go from an environment based around structure to an agile one, not just from a process perspective but from a cultural perspective.”
So Ms. Hamilton-Whitaker started the process of moving to a fully agile digital division by adopting an iterative waterfall approach. This introduced the idea of shorter sprints and additional checkpoints while maintaining a level of structured process and planning. Her technique involved dividing larger initiatives into sub-projects performed by different teams working in parallel.
At one end of the spectrum, traditional waterfall involves extensive up-front planning, a relatively hierarchal team structure and a sequential order of work followed by a “big finish,” Ms. Hamilton-Whitaker explains. “At the other end, there's agile, which encourages cross-functional teams, ‘just enough’ up-front planning, very short sprints of work and data-driven development: Release something, see how it performs, then iterate.”
In between lies iterative waterfall.
“The approach allows teams to dip their toe in more incremental deployments while maintaining structure and formality across functional or departmental areas like testing or development,” says Bill Fournet, president and CEO of The Persimmon Group, a project management consultancy in Tulsa, Oklahoma, USA.
COURTESY OF TARA HAMILTON-WHITAKER AND AGILE 101
Here's a look at why iterative waterfall might be right for your next project, as well as potential risks to consider before you opt to use it.
WHY ITERATIVE WATERFALL WORKS
You learn as you go. Because traditional waterfall is driven by early planning, it works well when much of the project information is known up front and is unlikely to change significantly during execution, says Jeff Oltmann, principal consultant at Synergy Professional Services, a portfolio and project management consulting firm in Portland, Oregon, USA.
For projects where knowledge discovery will continue to take place throughout execution—research initiatives, for example—iterative waterfall may be the right option.
“With iterative approaches, you have built-in cycles of experimentation,” says Mr. Oltmann, who's also a faculty member in the division of management at Oregon Health & Science University. “You learn a little, you plan your next segment and then you execute a little.”
The same is true for projects with a high risk of change. Mr. Oltmann recalls a project to improve the quality of bionutritionists' quality management processes. The team started using traditional waterfall, planning the entire yearlong project up front.
“We ran into problems because the sponsor would frequently change her mind about where the team should focus its efforts,” he says. “The team spent most of its time changing the plan rather than executing it.”
Switching to a more agile-like approach enabled the team to create shorter iterations of work, each dedicated to improving a particular process. “We had a high-level roadmap guiding us and decided the specific details of each iteration on a month-by-month basis,” Mr. Oltmann explains.
It can reduce resource bottlenecks. Iterative waterfall enables work traditionally done in separate phases of time to be performed simultaneously across multiple functions.
Traditional waterfall, in contrast, can make it difficult to manage resources, Ms. Hamilton-Whitaker says. Previously, when her organization used the traditional waterfall approach, specialists were brought in for development, and employees were responsible for testing.
“We often found that the specialists would plow through the work associated with their area of specialism but would wait until late in the sprint to merge their efforts,” she says. “This caused teams to bottleneck on the last few days of the sprint while waiting for the test analysts to test a sprint-worth of work for the first time.”
Iterative waterfall mitigates this risk by allowing the requirements team on, say, a software development project to work on some tasks while the testing team works on others and the build team prepares for others still.
By having team members work in parallel, “in the end, you can reduce the time between project start and deployment,” Mr. Fournet attests.
It delivers value before the project ends. With iterative waterfall, project teams are encouraged to release benefits of their work regularly during the course of the project, Ms. Hamilton-Whitaker says. And by front-loading the project with the most profitable or highest value deliverables, and releasing them as soon as possible, less up-front investment could be required to deliver the project.
If you need US$1 million to deliver a project but the bulk of the ROI will be delivered after the first US$100,000 is invested, the initiative could become self-funding, she explains. “The more you can break down a project and start releasing benefits, the sooner you can start earning your money back.”
POTENTIAL RED FLAGS
One of the main attractions of an iterative approach is its simplicity compared to agile, particularly for less-mature organizations, Mr. Oltmann says. But as with the introduction of any new process, the change must be managed carefully.
“Iterative waterfall can easily overwhelm an organization just being introduced to project management,” he says.
Additionally, because iterative waterfall does not deliver all project deliverables in one neat package upon close, some stakeholders may not be satisfied with what they're given in earlier phases.
“You might deliver parts A and B after an earlier phase, but the stakeholder wants to see more than that,” explains Baxter Mickey Rains, PMP, project and program management office manager at Integratek, an IT services division of the consultancy Pharma-Bio Serv in Dorado, Puerto Rico.
To mitigate this risk, project managers must manage stakeholder expectations for deliverables and milestones.
“The stakeholders should be closely involved with the scheduling process, and project managers should communicate to them, ‘These are the types of things you will see early on. We will more fully develop the details in the next iteration,’” he says.
Because iterative waterfall involves many moving parts, project teams risk losing sight of priorities, compared to traditional waterfall where project teams can focus easily on when a new phase will begin and a certain deliverable will occur, Mr. Fournet says.
“With iterative waterfall, as some teams get further into the project, they could go down tangential paths that cause them to not hit the scope originally requested,” he says. “I might ask for A and B, but the team realizes it also can give me C. If in the end, they give me A and C, they have failed.”
Project teams using iterative waterfall techniques also have to pay close attention when handing off parts of the project to the next iteration, Mr. Fournet says.
“In a software development project, for example, the build team might hand over a high-level design to the testing team, which is fired up and ready to go,” he says. “But the build team only wants a certain number of basic testing done on the prototype while it builds out the rest.”
THE BENEFITS OF FLEXIBILITY
The traditional waterfall method simply would not suffice for a current IT project at the Puerto Rico Department of Health, says Baxter Mickey Rains, PMP, Integratek, Dorado, Puerto Rico. Throughout the project life cycle and whenever possible, new government regulations constantly have been introduced, each of which must be accounted for in the scope.
“Using traditional waterfall would mean we'd have to go through another proposal process, perhaps crash the schedule and work additional resources to be able to incorporate every additional change,” he says.
The team instead opted for iterative waterfall to take advantage of its built-in flexibility.
“The iterative model allows us to continue with the original set of requirements but easily incorporate new requirements and adjust resources as we go,” Mr. Rain says.
Key to making it work is ensuring that the client is well aware of how the changes will affect constraints. The project's technical lead is responsible for identifying other aspects that might be affected by the changes and communicating that to the project manager, who in turn informs the client.
Using the iterative waterfall method has not only helped the project team cut time and costs but also kept the customer satisfied, he says. “We've been able to achieve a much higher level of satisfaction by delivering the product to them as necessary to meet business demands.”
Source: Jama's The State of Requirements Management 2011 survey of more than 800 software developers and project professionals worldwide.
If that specific information isn't communicated to testers, they mistakenly may start full-blown testing.
Project managers should clearly communicate and continuously reiterate the ultimate objectives of the scope to team members.
Mr. Fournet created a simple graphic illustrating all the parts of the project, how they relate to one another and the overall objectives. Team members saw this image during every status meeting. “It reminded people why they were there,” he says.
JUST A PHASE?
The decision to use iterative or traditional waterfall on a project doesn't have to be all or nothing.
“Any given project may need an emphasis toward one or the other. One approach does not fit all projects,” Mr. Oltmann says.
Project managers could even take a hybrid approach, whereby iterative waterfall is used during the planning stages, the traditional approach is used during the middle, and iterative is used again toward the end, Mr. Fournet suggests.
Engineering, construction, and oil and gas projects, for example, could benefit from a hybrid approach, he adds. “Once you start ordering and procuring materials and equipment, it's more difficult to go into the iterative approach.”
The bottom line? “Techniques from both approaches should be part of your practitioner's toolkit,” Mr. Oltmann says, “and you must develop the judgment and skill to be able to apply the best technique to a particular project situation.”PM
* Heavy up-front planning
* Sequential order of work
* Less up-front detailed planning
* Shorter work iterations
* Least up-front detailed planning
* Very short work iterations, or sprints