Get certified - Transform your world of work today


Program Failures When Your Organization Is Not Ready for Agile

Don't mix Agile and Waterfall

9 February 2016

Srinivasan Krishnamoorthi
HCL Technologies Ltd



I worked in a program recently wherein part of the work was done in Waterfall and the other part was done in Agile. The program ran into trouble quickly due to an unrealistic plan and unknown expectations. The organization, like many, had multiple suppliers and divisions, and the business units were also diverse. This mix created difficulties in managing programs that involved cross-functional teams.


Although the timeline for the program had been decided, the requirements were at a high level and were framed to be worked under the Waterfall approach. The team working in Agile was set to create six sprints during the six-month Waterfall window. With the initial high-level Waterfall plan, the Agile team had taken the deliverables required for integration -- without investigating the dependencies. During sprint three, the Waterfall requirements were delayed and the delivery dates were moved, affecting the Agile team's sprint. The traditional Waterfall managers were urged to replan and supply the Agile team with the required components so that the Agile team could arrive at a business value at the end of their sprint.


The Waterfall team's situation created tremendous impact due to the replan, which also increased rework. The reason is that the dependencies for the components had not been fully developed, which affected the project time lines by more than a month. This could have been avoided if the Agile team had been cautious about the dependencies and had planned for impacted sprints later in the cycle. The impact could have also been minimized if proxies were planned for the integration, using service virtualization or some other available tool or technique.


It is essential that Agile teams use techniques to avoid delays in their sprints. Sprints should be planned without hard dependencies. Any dependency from cross-functional teams should either be managed with proxies, or the sprint should start only after the availability of the dependency. Otherwise that dependency can disrupt the team and strongly and negatively impact the value derived from the sprint.

Organizations should also, whenever possible, avoid mixing Waterfall and Agile development within a single project.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3 (2 ratings)


Tim Baffa, CSM, 2/10/2016 4:06:48 PM
Your example is actually humorous, since it proposes a very un-Agile approach to producing business value.

It seems that your program was simply managing part of the "project" through iterative development cycles that were both fixed-scope and still dependent on other project work. A very restrictive and ugly approach indicative of a lack of understanding of Scrum and Agile principles and practices.

There are ways however for Agile and Waterfall to co-exist. The Agile portion must be relieved of any dependency on outside systems or efforts. This can be accomplished through "stubbing" various expected inputs and outputs based on current understanding. The Agile work can then proceed as needed, awaiting the true integration testing whenever the Waterfall portion is ready.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up