Agile or Waterfall, which method should project developers adopt?

Speed in execution is key, and agile methodology with lightweight managers is pursued, similar to scrum masters for rapid time boxed execution
Image: Shutterstock

Agile appears to be the way to go, as project manager after project manager and company after company seem to swear by it.  The IT and software industry was amongst the firsts to adopt this approach as often the end objectives (what their customer wants) keep changing and the flexibility afforded by the agile methodology is welcomed. With the successes achieved in various projects, eulogies have been overflowing for the agile method. With almost every industry evolving fast, gross uncertainties, and if the product under development is late to the market, the calls to adopt agile grow.  It is impossible, on any given day, to not come across some article that attempts to show how agile can be adopted in yet another industry. The traditional approach adopted by most industries has been the waterfall method where the objective of the project is known in advance and the project progresses through identified stage gates. Then what is it that agile can do that waterfall cannot? Can agile really replace waterfall? Or is it noise without substance?
 

Why do companies do projects? There is a plethora of reasons: new products, new processes, change in businesses, and so on. The decision on whether to proceed with a waterfall or agile method is more seen in product development projects where a company plans to enter a market with a product but may need to change track midway if market needs and expectations change. These product development projects can be broadly divided into research and development projects. In research projects, companies seek answers and solutions to supplement knowledge and capabilities, akin to breakthrough projects. Development projects, on the other hand, have a definite goal in mind and the waterfall method has been traditionally adopted across most industries.
 
Every company creates a portfolio of breakthrough (research), and platform and derivative (development) projects that it may want to pursue. This portfolio is a fallout of the business strategy that the company would have adopted. Companies allocate their resources across projects, time and sequence these projects accordingly. Breakthrough projects usually have the highest risk profile of all projects. They are usually treated as discovery-driven projects where often several approaches are simultaneously investigated towards certain initial broad goals. Such projects are pursued to build a knowledge and capability base from which the company may profit in a little distant future. Teams that pursue such projects tend to be small, collaborative and co-located. While it may be tempting to term this as an agile approach but almost everything in such projects is rare: the net outcome of such projects is rarely well defined, commercialisation rarely on the anvil, and rarely are there any set of rules or processes to be rigidly followed. Rather we can say that such projects need nimble autonomous teams which can pursue the search objective.
 
Platform projects are the primary vehicles that an organisation utilises for developing its future capabilities and eliminating existing rigidities, and thus determining its future competitive direction. They must produce fundamental improvements in the cost, quality, flexibility, or performance, and incorporate real options for the future. This requires platform projects to have considerable up-front planning and significant integration of different functional specialisations to develop the whole product. This necessitates the need for strong processes, periodic review mechanisms, and the correct constitution of the project organisation. More than the speed of development, developing the platform of right integrity is more important because platforms provide the options for future derivatives. Thus the waterfall method with a strong heavyweight manager is necessary for platform development. Some aspects of agile development such as working in parallel work streams and prompt incorporation of customer feedback though are increasingly getting adopted in such waterfall development pursuits.
 
In contrast, derivatives are spawned by platforms, either initially planned or as a market reaction. A platform never goes to the market, but a platform is said to have been launched when the first derivative from the platform reaches the market. A platform development could have a couple of derivatives planned along. Besides new products or improvements that such projects may entail, derivative projects largely represent incremental changes over existing products or processes such as new packaging, more efficient manufacturing, or a no-frills version for a cheaper market segment. Given this magnitude of development, speed in execution becomes key and agile methodology with lightweight managers is pursued, similar to scrum masters for rapid time-boxed execution. Here the whole panoply of agile methods—scrums, sprints, and kanban—comes into its own with considerable benefits.
 
So, might there be some life left in the old waterfall method yet? It appears to us that, across the whole range of projects—breakthrough, platform, and derivative—a judicious choice of agile and waterfall methodologies holds the key to yielding the maximum benefits. Knowing which methodology to adopt for which project is necessary for proper aggregate project planning of the portfolio of projects which enables the resource allocation and timely release of products into the marketplace.
 
Views expressed are personal
Anshuman Tripathy, Faculty, IIM Bangalore.
Sudhir M Chadha, Adjunct Faculty, IIM Bangalore.

[This article has been published with permission from IIM Bangalore. www.iimb.ac.in Views expressed are personal.]