Agile vs Waterfall?
“Agile and Waterfall methodologies are like oil and water. They don’t mix.”
“Software development is totally different from hardware; Agile only works for software”
“Applying Agile is all or nothing”
“You must be able to ship every two weeks”
We hear these statements all the time from hardware teams that are trying to increase speed and predictability in their product development projects. The reality is that hybrid processes that mix the discipline and long-term planning of the Waterfall model with the adaptability and speed of Agile are not only possible – they are best-in-class.
Myths Hinder Adoption
The myths about Agile development generally come from those who aren’t students of the discipline but merely observers from the side. They’re correct that a rigid application of Agile software development techniques to a hardware development team would break down quickly. However, when modified for the unique characteristics of hardware design and manufacturing, there are key elements of Agile Product Development that allow teams to gain the project management, speed, predictability and product definition advantages that their software counterparts enjoy.
The Agile Manifesto – Not Just for Software
Our experience with clients, as well as our primary research, explode the myth that Agile is all or nothing and that it is inapplicable to tangible products. The Agile manifesto itself refutes the notion that Waterfall approaches and Agile are mutually exclusive.
Of the twelve Agile principles contained in the Manifesto, 75 percent are not specific to software development projects. For example, such concepts as “Business people and developers work together daily”; “Projects require motivated individuals, support & trust” or “Face-to-face conversation is most efficient” are not software specific. There’s no reason that these principles of agile software development cannot operate in any product development environment.
There are significant differences between tangible products and software, but nothing prevents developers from importing select principles from Agile teams to other environments. Research we conducted showed that the use of sprints, having an iterative approach, and developing a local build capacity were used effectively by tangible product developers. Our experience with clients shows that selective use of tools from the Agile/Scrum toolbox is not only possible but that it also reduces team burnout, brings teams closer to customers, and improves the adaptability of product teams to shifts in markets or technologies throughout the product lifecycle. It’s not all or nothing.
Embedding Agile Within a Waterfall Methodology
Applying Agile to hardware products does not have to be an “all or nothing” process. If teams have a phase gate or milestone-based process, they can achieve the best results by applying modified agile methods within their current process and project management methodology.
The key to gaining this competitive advantage is to divide long product development timelines (12-18 months) into sprints, a tool frequently used in Agile software.
Then, nest these sprints within the Phase-Gate/Milestone framework. Using sprints within this larger framework accelerates decision-making. Sprints also divide a long journey into smaller steps, with concrete deliverables, within a fixed duration from two to four weeks. This division of the product development timeline into smaller units increases urgency and keeps the team on task. The results are less waste and faster product development timelines.
But developing tangible products also requires the discipline and planning that Phase-Gate/Milestone processes afford. These longer-term cycles of planning provide the financial controls that tangible products require. Unlike many software products, the development phases for tangible products tend to involve numerous stakeholders: functions, partners and suppliers. Unlike software, they often involve dependencies such as tooling, material buys and inventory control. Traditional, waterfall development approaches with gated processes also prevent budgets from ballooning out of control.
For many products, regulatory or qualification cycles are also essential facets of the product plan. For these reasons, tangible products require an end-to-end product plan, with a comprehensive schedule to ensure that project requirements are satisfied.
Adopt Agile Methodology Incrementally
At its heart, adopting Agile methodologies requires organizational change management. The adoption does not happen overnight, and in large organizations, not even quickly. And it’s much more than adopting new project management software.
A proven approach is to pilot agile project management, using team members who have a track record for embracing improvement. Organizations will learn quickly from pilot initiatives and then they can improve in increments. Start with a clean slate, introducing your new methodology from the very beginning of the project.
Agile gurus and guidebooks are sometimes too rigid, imposing an orthodoxy that doesn’t make sense for your culture or your products. Start small, learn the basics, and then improve by modifying the tools to fit your environment. Maybe it’s Gantt charts, or kanban, or project prioritization, or customer involvement, or adding a more robust testing phase, or some other practice that works for you.
High Performance Teams = the Secret Sauce
We’ve discovered that much of Agile’s success depends upon high performance teamwork. That means:
1) Upper management has empowered project teams to plan and prioritize their work;
2) Team members have both domain expertise and collaboration expertise that shows up in the final product;
3) Middle management changes their focus from micro-managing to removing roadblocks, and
4) Everyone puts product allegiance over functional allegiance
High performance teamwork requires a new way of working, throughout the development lifecycle, but the most successful companies have mastered this challenge and are reaping the rewards. For others, high performance teamwork is the gateway to entering the next phase of product development excellence.
Many teams are losing an opportunity to accelerate product development because of unexamined assumptions about the Agile approach. The myths create one of the tallest barriers to adoption. A lack of prescriptive best practices for adapting Agile principles to tangible products is another hurdle.
But changing minds and adapting what works is possible. In fact, it is necessary for staying ahead of the curve of product development speed. Companies that have mastered teamwork, through every phase of the project, are more than half of the way there.
Another key success factor is sprint planning. Define the sprints that are nested within your phase-gate process very carefully. Use short intervals, and define the goals, deliverables and metrics for each sprint with as much precision as possible.
Finally, give yourself adequate time to pilot and adopt Agile principles to your environment. Corporate culture tends to play a larger role in tangible products and change takes time. The culture must adapt to the fact that, when you bring Agile tools to the job, functional managers must cede some of their control. Since teams that develop tangible products tend to be cross-functional, there are more functional managers, that is, more cooks in the kitchen. This can be a challenge when your team is trying to pilot workflows, sprints, product owners, agile testers, daily meetings, backlogs, and other Agile project management tools that help to accelerate your teams. Again, your best approach is to learn the basics, start slowly, and adopt only what works for you.