Scrum vs. Waterfall Round 2: 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 of Agile methods. Both allow for the use of a variety of techniques. To be effective, both require an appropriate amount of rigour, 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 rigour for the project at hand.

Similarities

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

1. Have processes to request, approve and prioritise changes. Both put focus for the approval and prioritisation on the Business (product owner/sponsor/SMEs).
2. Stress the importance of communications.
3. Allow for more or less rigour, as appropriate.
4. Find communications easier when the teams are co-located.
5. Both face more challenges with virtual teams.
6. Have processes to manage the scope.
7. 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 organisations have their own methodologies, so their processes for completing business analysis vary extensively. Also, many organisations 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 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 prioritised 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 prioritised 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. More later!    

Elizabeth Larson is Co-Principal and CEO of Watermark Learning  and has over 25 years of experience in project management and business analysis. She has presented numerous workshops, seminars, and training classes since 1996 to thousands of participants on 3 different continents.

Elizabeth has co-authored the CBAP® Certification Study Guide (2nd Edition) and Requirements Management, Part I: Requirements Planning. She has also co-authored numerous articles on project management, business analysis, and influencing skills published worldwide. She has co-authored works published in two compilations, Creating a Clear Project Plan, compiled by Dr. Gary Richardson and published by the University of Houston. The other is Projects Without Borders: Gathering Requirements on a Multi-Cultural Project, published by Icfai University Press. She has also been cited in CIO and PM Network, PMI's monthly publication.

Elizabeth was a lead contributor to the PMBOK® Guide, 4th edition and can be contacted at elizabeth.larson@watermarklearning.com.

Comments page 0 of 0

Click here to add a comment

Your Name:

Image Verification:

Comment:

 

There are currently 0 comments to display.

<>