Waterfall or Agile? Do Both!

“Agile and Waterfall development processes 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 Waterfall with the adaptability and speed of Agile are not only possible – they are best-in-class.

Myths Hinder Adoption

The myths about Agile 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 techniques within a hardware development project would break down quickly. However, when modified for the unique characteristics of hardware design and manufacturing there are key elements of Agile that allow teams to gain the 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 Phase-Gate/Milestone and Agile are mutually exclusive. Of the twelve Agile principles contained in the Manifesto, 75 percent are not specific to software. 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 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 to other environments. Research we conducted in 2014 showed that the use of sprints, having more iterations, 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 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. It’s not all or nothing.

Embedding Agile Within Waterfall

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. 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 of 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, developing tangible products tends to involve numerous functions, partners and suppliers. Unlike software, they often involve tooling, material buys and inventory control. Traditional, 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 launch requirements are satisfied.

Adopt Agile Principles Incrementally

At its heart, adopting Agile methodologies requires organizational change management.  The adoption does not happen over-night, and in large organizations, not even quickly. A proven approach is to pilot a project, using team members that have a track record for embracing improvement. Organizations will learn quickly from a pilot and then can improve incrementally. 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.

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 teams to plan and prioritize their work;

2) Team members have both domain expertise and collaboration expertise;

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, but the most successful companies have mastered this challenge and are reaping the rewards.

Missed Opportunity

Many teams are losing an opportunity to accelerate product development because of unexamined assumptions about Agile. 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 are more than half of the way there.

Another key success factor is to 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 great care.

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 work, 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 sprints, daily meetings, and other Agile tools that help to accelerate your teams.