Watergile: An Agile Hybrid Approach for Enterprise
Although Agile development methodologies were first proposed for product development in 2001 and gained popularity for software development in the mid-2000s, corporate enterprises have only recently begun to embrace the Agile approach. However, Agile development is not well-suited to all products and organization structures, often necessitating an approach that combines Agile with more traditional Waterfall practices. Doing this effectively without simply ending up with the worst of both worlds is challenging, but leads to strong outcomes when done well.
Why Agile?
Agile development has at its core several key concepts that were quite novel when the methodology was introduced:
- Individuals and Interactions over processes and tools
- Working products over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These concepts together are designed to do two things:
- Develop products quickly with low ramp-up time
- Add new features and abilities iteratively over time until a product is “complete”
This approach is very different from traditional Waterfall practices that instead place emphasis on strong up-front planning and a “develop everything at once” plan of action. In an ideal world, Agile development comes with several advantages that have made it a standard approach in the software world. By eschewing a lengthy planning phase and jumping into development to meet customer requests, Agile is a way to get a core product up and running quickly without worrying about meeting every single need right off the bat. Additionally, the iterative development and launch process of Agile leads to frequent releases that allow stakeholders and customers to see progress and interact with new features on a regular basis rather than waiting many months to see a final product.
What is Agile Good For?
It is important to remember that the Agile methodology was originally created specifically for software development. This is because Agile lends itself to products that have a core set of functionality that can be developed quickly, with additional features and functions added on later. In the software world this often makes sense since a software product usually has core functionality that is required, with “nice to have” features surrounding it. For example, a customer portal’s core functionality might be “view my information and pay my bill online”. As long as this functionality works well, the portal is useful to customers. Features like “add new services” or “view deal offers” can be added later without issue. As a result, Agile development would produce a good enough core product quickly and add additional features later, saving time and potentially money in the process.
However, many enterprise products do not naturally lend themselves to Agile development. Physical products for consumers, like cars, phones, and computers, are typically a poor fit for Agile. Imagine buying a car that comes as a box on wheels when you purchase it, and then every month someone comes out to install power windows or an infotainment system. Or think of an Agile phone that can only make and receive calls when you buy it, then two weeks later it can send text messages and two weeks after that it can go online, etc. No one would purchase these products. This is why the Agile methodology is naturally at odds with products where customers expect a feature-rich, fully working product on launch day.
As a result, corporate enterprises are increasingly faced with a difficult situation. On one side, software development is embracing the Agile methodology, but on the other side physical products that need to integrate with software components are limited by real-world concerns and require slower, more Waterfall-oriented development practices. A hybrid approach is needed to bridge this gap.
Watergile in the Enterprise
A key opportunity for enterprises seeking to bring the Agile methodology to product development is to embrace an approach that combines aspects of both Agile and Waterfall in a way that capitalizes on the strengths of both. We call this approach Watergile and have helped many clients implement it with great success. Here is how it typically works in practice:
- A Waterfall-style fixed launch date is still set for all product functionality
- Agile-style development phases and internal releases are executed to meet the launch date
- Up-front planning and project oversight are lighter than with Waterfall, but slightly more rigid than with Agile
- Documentation is more defined than with Agile, but significantly less formal than with Waterfall
While this approach sacrifices some of the flexibility and speed of pure Agile development, it ensures that product development progress is checked internally and that the final product released to consumers is fully market-ready. The net result is a process that is faster, cheaper, and more nimble than traditional Waterfall development for products with real-world constraints. However, achieving the right balance in this approach can be challenging and requires consistent guidance to prevent people and processes from sliding out of alignment. Our team of experts can help your organization spearhead, implement, and lead Watergile programs that meet enterprise-level constraints and goals.
