Application Services provides a platform for IT Development and Maintenance professionals to discuss and gain insights into best practices, process innovations and emerging technologies that will shape the future of this profession.

« Distributed Agile vs collocated agile - Is it important to be in the same room? | Main | Website Upgradation: Creating a compelling multi-channel experience for your customer »

Striking the Balance: Waterfall and Agile - Part I

Today, companies have a plethora of choices such as SCRUM, Extreme Programming (XP), Behavior Driven Development (BDD), Feature Driven Development (FDD), Lean and Kanban software development methods under the umbrella of agile along with exiting waterfall method for project implementation. Companies can select the best combination of suitable methodologies to maximize business value for the customer.

In this blog series, we will discuss various methodology selection aspects across dimensions such as business/ application, location and teams, tools and also explore best-practices in both methodologies to balance agility with discipline and control.

This blog will talk about the methodology selection pointers around business and application related dimension. 

It is important that, methodology goals are aligned with project goals. Projects are more suitable for agile development when the primary project goals are rapid value delivery and responsiveness to change. Waterfall will the right approach for projects that demand higher predictability, stability & assurance. 

Agile adoption is more suited to projects that cover significant enhancements, entirely new development or initial prototyping of a new concept especially in dynamically environments where the requirements are emergent. Waterfall is useful in projects where:
  • There is a need to integrate several independently evolved applications
  • Improperly modularized existing systems that need to be replaced incrementally
  • Stakeholders desire to have rigorous manual and exploratory testing
Agile initially started with small to medium teams of people working on relatively small applications due to tight coordination and shared tacit knowledge constraints. However, recently, many large scale programs have documented successful delivery of agile transformation by use of scaling options available like Disciplined Agile Delivery (DAD), Scrum of Scrums (SOS's), Lean Kanban, Scaled Agile Framework and SAFe. 

For very large projects where plans, documentation and processes enable better communication and coordination; when the requirements can be determined in advance and remain relatively stable across large and dispersed groups; waterfall approach can be effective.

Agile can be used in projects with greater dependencies with mitigation through following certain practices but with reduced benefits that agile has to offer. Waterfall manages multiple dependencies and constraints as well as systems complexity through upfront detailed planning and coordination.

A successful project needs to fulfill the following prerequisites of customer relationship, i.e., Collaborative, Representative, Authorized, Committed, and Knowledgeable (CRACK) business partners and representatives. Agile approach is well suited to projects where 'crack' performers such as product managers and product owners are identified and dedicated to the project. This allows scope for immediate response and clear decision making, enhancing communication between the entire team, thus reducing risk and uncertainty. In waterfall, some form of contract between the developers and customers is required as the basis for customer relations. They handle foreseeable problems by determining it in advance and formalize solutions in a documented agreement. 

In Agile, undocumented, unclear or poorly defined requirements present very little difficulty and align well with an agile methodology that proposes 'just enough' documentation whereas in waterfall requirements have to be documented in detail such that the designers can accurately and proactively predict flaws. Also, sufficient number of resources has to be allocated for elaborate documentation to keep up with the goals of predictability, stability and assurance through standardization and process capability.

Agile and waterfall are not exclusive, but there has been considerable polarization associated with both approaches and much of these differences are rooted more in perception and misconceptions rather than in reality. In many cases, the manner in which companies apply their judgment and skills in using the methodology has a higher impact than the methodology itself.

In the next post, I will discuss about how Location and Team dimension impacts methodology selection considerations for waterfall and agile.

References:
  1. Balancing Agility and Discipline: A Guide for the Perplexed By Barry Boehm, Richard Turner
  2. Agile Project Management with Scrum Ken Schwaber Microsoft Press, 2003

Comments

This is a great article and I realize a lot of organizations struggle to adopt the right methodology. What should be the other factors for determining if Waterfall or AGILE is a more appropriate methodology.

Great to know that you liked the article. I have written on subsequent around waterfall or agile dimensions and will published as series of blogs. Look out for this space.!!!!

Agile works with business that is prepared to launch product / feature incrementally , when requirements are known . Waterfall is wise when Agile adoption at customer is still not clear and business can wait with requirements still evolving . The ROI of Agile cost and timelines in terms of matured set up is much more and business does not have budget to spend 2 years or so to wait on getting Agile transformation readiness.

Thanks Vikram for your comments.
Typically in today's volatile business environment.It is difficult to get "requirements which are known ", from stakeholders, change is inevitable and can be best accommodated in agile practices.
In waterfall, where application is stable, well known to the team, requirements can be agreed upon between business & IT, it is easy to practice BUFR /waterfall way of work.
Agile promises long term sustainable continuous improvement.
Well thought out budget spent on change management initiatives of stakeholder mindset shift and agile transformational readiness will improve overall agile delivery across projects/programs/portfolios.
Enterprise will exhibit agile adoption maturity and experience agile benefits like better productivity, cost optimization , quality, predictability/ commitment, stakeholder satisfaction along with timely business value delivery ,accelerating higher and higher ROI.

This is an awesome article and I understand a considerable measure of associations battle to receive the right approach. What ought to be alternate variables for figuring out whether Waterfall or AGILE is a more fitting procedure.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.