Categories: Business AnalysisScope CreepScrumWatermark Learning

Scrum vs. Waterfall: The Fight Continues

Last month we began our “fight” by exploring two estimating techniques that are often used on both Scrum and Waterfall projects. The first was relative sizing (one kind of analogous estimating) and the second Delphi (called Planning Poker in Scrum). Scrum won both rounds (barely) because although both techniques can be used on both types of projects, their usage in Scrum seems easier to understand, learn, and apply. I don’t know about you, but when I hear the terms Analogous and Delphi I think academics and hard work. When I hear about tee-shirt sizes and planning poker, I think fun.

This month, inspired by a debate on Agile vs. Waterfall, presented by the Phoenix chapter of IIBA, I want to compare Waterfall to Scrum in a variety of different ways. As I listened to the two sides during the debate, I was amazed at the number of the similarities, as well as the importance of the subtle differences. This month’s blog will explore both the similarities and differences. Before I begin, I want to stress the point that neither one is a methodology. Neither is prescriptive. Waterfall is an approach. Scrum is a framework, part of the myriad Agile methods. Both allow for the use of a variety of techniques. To be effective, both require an appropriate amount of rigor, although we acknowledge that both approaches have been implemented in a wide variety of ways. For the discussion below, we’ll assume the appropriate level of rigor for the project at hand.

Similarities

There are many ways in which these two approaches are similar. Both:

Have processes to request, approve and prioritize changes. Both put focus for the approval and prioritization on the Business (product owner/sponsor/SMEs).
Stress the importance of communications.
Allow for more or less rigor as appropriate.
Find communications easier when the teams are collocated.
Both face more challenges with virtual teams.
Have processes to manage the scope.
Estimate the work involved in business analysis whether phase (s), releases, iterations/sprints.

Differences

Many of the differences lie in how these processes are implanted. To understand the vast differences in implementation, we need to understand that many organizations have their own methodologies, so their processes for completing business analysis vary extensively. Also, many organizations use hybrids or “best of “breed” implementations. With that in mind, let’s examine some differences between Waterfall and Agile.

Intricate, large projects

On large, intricate projects with many business and technical interfaces and impacts, with a variety of cross-functional SMEs or with many compliance regulations, there are advantages to the Waterfall approach. While these projects can also be implemented using Scrum, it is harder when there are project dependencies.

Coding and testing. On the large projects I managed, we were always touching programs and test data that other teams needed and vice versa. It seems to me that following a detailed plan places less stress on all the teams. Even when slippage occurs or the team completes programs earlier than anticipated, following the plan and communicating variances in a more formal and proactive way is helpful to all the teams involved. Again, it can be done using Scrum of Scrums or other processes, but I have found that following a plan is a stress-reliever.
Incorporating changes. Again, when there are approved changes and there are significant project dependencies, it can be helpful to change the plan, so that a schedule for completing these changes can be determined and communicated to everyone impacted by the change. This is particularly true when the approved changes have significant impacts and can cause changes not only to work completed by the team, but by work already completed and tested by other teams.

The winner: Waterfall!

Defining requirements when they are highly volatile

Waterfall projects have approval points, often called toll or stage gates. When requirements are unstable, business analysis can seem to take forever and the sponsor may get frustrated with what appears to be analysis paralysis. I once had a sponsor tell me that he had never seen analysis take so long, but was surprised and delighted that the project get done so quickly once we had the requirements. Thoroughness in requirements definitely paid off. However, there was significant frustration as the churn was happening.

Scrum projects have the wherewithal to handle this kind of churn better in my opinion. User stories that are pretty well understood are closer to the top of the product backlog and are ready for inclusion in upcoming sprint(s) than “epics” that are less understood.

The winner: Scrum!

Managing scope and changes

On Waterfall projects schedule, cost, and scope baselines are established (as well as others). These become project constraints. When changes are approved and prioritized by the Business, the sponsor, often upon the recommendation of the project manager, needs to decide which of the baselines will change. I have talked to many Scrum proponents who argue that Agile projects expect change, but Waterfall projects do not. This assertion is simply not true. I have yet to be on or hear of a Waterfall project that did not expect changes. Having said that, modifying the schedule, particularly when it involves changing dependencies, can be cumbersome and frustrating.

I think managing scope on Scrum projects is easier in many respects, most of which relate to the fact that having small sprints helps the framework accommodate changes with far less pain. In addition, I have seen more consistency in the way changes are requested, approved, and prioritized on Scrum projects.

The winner: Scrum!

I could go on with this comparison, but my little blog is turning into a full-fledged article, so I’ll simply list out areas where I think Waterfall wins and address them in more detail in future blogs.

Waterfall wins in these areas:

Effectively using the role of the BA to define requirements completely using a variety of elicitation and modeling techniques. Although Scrum is catching up, it still lags behind.
Defining the business need and business case. Most of the visioning I have seen on Scrum projects has tended to be superficial. Again, this may be due to the way I have seen it implemented.
Getting from the “as-is” to the “to-be.” Ensuring that the solution in general and software in particular supports business processes or if not, that the business is ready for the change with such things as new processes, training, the required sales, marketing and support resources, etc.

Of course Scrum wins in some other areas, too…

Elizabeth Larson, PMP, CBAP, PMI-PBA, CSM

Elizabeth Larson, PMP, CBAP, CSM is a consultant and advisor for Watermark Learning/PMA. She has over 35 years of experience in project management and business analysis. Elizabeth has co-authored four books and chapters published in five additional books, as well as articles that appear regularly in BA Times, Project Times, and Modern Analyst. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as the several of the PMI standards. Elizabeth also enjoys giving presentations, and her speaking history includes repeat keynotes and presentations for national and international conferences on five continents. Elizabeth enjoys traveling, hiking, reading, theater, and spending time with her 7 grandkids.

Next Is the BA a Product Owner or Tester On Agile Projects? »

Previous « Are You My Sponsor?

View Comments

Jeff Gordon says:

July 6, 2010 at 1:26 pm

I believe there is a fundamental differences which even the heavy hitters of agile never put their fingers on. This viewpoint was extracted from the writings of the early agile folks. In earlier years I developed high performance teams. What we found is that the relative "health" of the team was critical to our success. That health was dependent on a high degree of openness, trust, and recognition for each other's ideas as well as confidence that we were pursuing mutually benefical objectives. Recognition of each other's ideas was an indicator of how much openness and trust existed. Follow through and successful completion of assigned activities is another. A common understanding of the current state, baseline and shared vision of the future state was also most critical to the success of the group. Use of vehicles like sharepoint or a common area on a network for team materials in ongoing development for real time discussion and update is essential. We used meetings only when the group process was needed to resolve issues or make decisions. Everyone was trained in tools and techniques for systematic problem solving. Lastly; and most importantly, intensive feedback among all stakeholders, project members and users throughout the project. Treating each other's work with the utmost respect and the end user as the customer. What I am saying is that good old "Performance Management" avoids a ton of wasted time and gets a team to high quality results every time. Defining the Baseline and Future State. Setting measurable objectives and tasks, giving feedback throughout, and recognizing behaviors and results that contribute to project progress will get the team to success every time!
Martin Schedlbauer says:

July 14, 2010 at 10:42 am

The issue is not where Scrum and Waterfall are similar, but how they accomplish their tasks and how likely they will succeed in that. Of course, both approaches need to prioritize requirements. The question really is: which ones is likely going to be successful. The waterfall approach of asking stakeholders to prioritize most of their requirements early in the project lifecycle often does not work in practice. The Scrum approach of doing the prioritization at the beginning of each spring is more likely to succeed. Scrum plans "in the small" which is more tangible, whereas waterfall tends to plan "in the large" which is often too abstract for many stakeholders.

Jeff's comments on "team health" is also important to consider. Good Scrum teams are those that are relatively small and consist of high performance individuals. An interesting question is the following: what happens when you have to staff a Scrum project with "mediocre" resources either because that is what your company has or because those are the only resource left. Now, those individuals may need more guidance, hand-holding, and "management" -- the hallmark of traditional project management.

Scrum requires "willing and able" resources (as well as co-location, strong product owners, etc.) if you don't have those, Scrum is less likely to succeed and more traditional "performance management" may have to be brought to bear.
ElizabethLarson says:

July 16, 2010 at 12:50 pm

Jeff,
Great ideas for successful projects, regardless of whether the approach taken is Waterfall or Agile! Thanks so much for writing in! I, too as a PM have found your tips invaluable. The one I should have used more was feedback. Respectful feedback among the team and stakeholders throughout the project would have been a benefit to us all. Again, great tips and thanks!
Elizabeth
ElizabethLarson says:

July 16, 2010 at 1:18 pm

Martin,
You pose an interesting and important question: what happens when you don't have high-performance team member(s) on your Scrum project. I have seen some teams that are not uniformly high-performing start off OK, get frustrated, and then look to the Scrum Master to resolve conflicts, which is iffy at best. When the Scrum Master remains neutral and doesn't try to take on a leadership role, a leader often emerges who ironically is not the one who talks the most or has the most experience. My preference is for a strong product owners to get the team members motivated because forgetting chickens and pigs,if the project goes awry, the organization (represented by the product owner) doesn't get what it needs.