Elizabeth Larson, PMP, CBAP, CSM, CEO and Co-Principal of Watermark Learning (
Last month we began our "fight" by exploring two estimating techniques that are often used on both Scrum and Waterfall projects (view here). 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 co-located.
- 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 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. More later!
Don't forget to leave your comments below
Subscribe to this comment's feed
written by Nate1, June 15, 2010
-
- +2
-
-
written by alex_papworth, June 16, 2010
Unfortunately, I generally work in the worlf of very large corporates where the opportunities to apply it are rare (never in my experience). I have had limited exposure when managing a team of developers as part of a startup - very rapid learning curve but fun!
My comment relates to the management of scope and changes, especially cost. Many large organisations don't seem to have the right culture because of the governance processes around change. Typically, once a baseline has been set, any change may take upwards of a couple of weeks to be agreed, especially when there is a budget change.
This eems to relate to empowerment, or lack of, for individuals on the project.
Am I right in thinking that some organisations need a culture change before they can even conceive of piloting something like Scrum?
Or is it possible to set up and ring fence a suitable 'subculture' within the organisation where the necessary flexibility ad empowerment is allowed but without exposing the larger organisation to unacceptable risk.
Any thoughts?
Alex Papworth (Business Analyst Mentor)
-
- +0
-
-
written by a guest, June 16, 2010
Steve Orr (Capiro Ltd.)
-
- +0
-
-
written by darshilm, June 16, 2010
I do not know. I keep pushing with the argument that agile manifesto says "Working software over comprehensive documentation".
Any thoughts?
-
- +0
-
-
written by winter1610, June 16, 2010
I do see plenty of people out there trying to work Agile with a mindset that screams set procedures and process. Before long we have people obsessing about the Agile process and not the end result. How far forward have we come,
The other comment I'd make is that in any delivery that included mainframe changes Agile really struggles and is in danger of promising far more that it can achieve.
I've commented on this in my own blog if anyone would like to comment more.
-
- +0
-
-
written by kha, June 16, 2010
In my view and according to my experience there is no silver bullet.
Waterfall and Scrum are different approaches that must be used in the proper environment and for projects that suit them best.
Each comes with their own set of rules. For example, if you have the proper attention from your sponsor on a waterfall project, change management can be easy. However, not getting the proper attention from your product owner on a Scrum approach might get you some headaches to manage change.
I don't agree when you say that scope change is easier on SCRUM due to the fact that it is using small sprint. This might be true for changes impacting the sprint only. It becomes another issue if the change also impact previous sprints. You can achieve the same small scope change easily with the waterfall approach and maybe benefit from better traceability when it has a larger impact.
The important thing here is ensuring that everyone agrees with the rules of engagements and this can be a real enterprise culture challenge.
A word about documentation, every project requires it. The SCRUM approach is not denying it. Again here, it is related to the culture and environment (legal aspect, SOX, ...) of the emterprise. We all prefer working software over documentation. But, when your 2010 car fails you want the mechanic to rely on the 2010 car documentation not on the 2008 one. ;) We have to determine the right level of documentation and make it part of the definition of a what a completed SPRINT is.
I like to think that we have to use both approaches, even within a project. A complex large project might start using a Waterfall approach while executing part of it using SCRUM.
So no winner. Just two good approches. Just use the right one for the right project.
-
- +1
-
-
written by elizabeth.larson, June 17, 2010
1.I have heard clients say that on their Scrum teams they do not do traceability. I usually find that they do trace requirements (user stories)—to acceptance criteria, to test cases, to their release plan, and even to development. What varies is the amount for formality. In general the Scrum delivery teams I’ve seen do not use a traceability matrix. However, on projects where BAs work with the delivery team and groom the backlog prior to the current sprint, a traceability matrix is often created and maintained.
2.As far as producing a business requirements document, huge topic. Briefly, I advise my clients:
a.Document as much as you need to for clear communications, for compliance, and to reduce legal risk. But just enough.
b.If your organizational culture and/or processes require a formal BRD, not for the reasons stated above, provide a recommendation to the powers that be (PMO/ COE/ whomever) on “a” above. This recommendation will require you to understand the current situation, including the business need for the documentation, gather statistics (who uses the doc, how often it is referred to and why, how often is it changed and why, etc.). You will probably not be the decision-maker. But you might be able to influence the decision-makers to take a leaner approach.
c.A common misconception of the Agile manifesto is that no documentation is required on Agile projects. Keep in mind that to prefer working software over comprehensive documentation does not mean that teams should not document. But to document for the sake of documenting does not add value.
3.Ellen, although I didn’t see your comment on BA Times, I agree, I agree, I agree. And I’m so glad you’re addressing the entire solution with your clients!
-
- +0
-
-
written by ellengott, June 17, 2010
Thanks for your provocative and thoughtful post!
Balance is needed, indeed (as suggested in the Boehm/Turner book). Scrum is just a framework, so issues like traceability, documentation, visioning and product roadmapping need to be added into your project. I’ve seen large, complex project add these effectively to agile frameworks. DSDM (the grandmother agile method) is more explicit with some of these.
WRT the “role of the BA”; the key is not so much the //role//, as the work. And yes, agile projects VERY much need to use elicitation and modeling techniques that ‘traditional’ analysts know and use.
Some readers might be interested in reading more via “Agile Business Analysis in Flow: The Work of the Agile Analyst” (part I is here: http://www.ebgconsulting.com/Pubs/Articles/ AgileBusinessAnalysisInFlow(Part1)_TheWorkOfTheAgileAna
lyst_Gottesdiener.pdf
We (I am part of a volunteer group on this) are working actively on this topic in our IIBA BABOK agile extension. [For any and all analysts keen to follow our efforts, please go to http://agileba.pbworks.com/ ; work is in progress, slowly we are moving through the KAs in the BABOK and working on the Glossary and additional Techniques]
Business need and business case are actually very crucial to agile projects; after all you hear a lot about the “business value” mantra. The best agile teams pay careful attention to this (although some do a lightweight version to start, then pickup on business value definition more powerfully after the delivery team has some positive experience with making commitments).
I’ve written about how agile team using facilitated workshops to do this in the article “Agile Requirements by Collaboration”, posted here: http://ebgconsulting.com/Pubs/Articles/Agile Requirements by Collaboration.pdf
You are right, business process change is often part of any solution, and a holist view of this needs to be added into any agile project. These points out how truly important enterprise analysis is to any successful project. In particular, lean/agile addresses looking at the entire value stream (via value stream mapping), and does this not just for the solution delivery process (e.g. using lean/agile to delivery the product), but also to address delivering the right solution, or parts of it, to the end customer.
Elizabeth: addressing more than just software is vital, and thanks for pointing that out!
Right now I’m working with a client with a decent set of backlog items for the software product, now realizing they need to add into their product roadmap and product backlog items that address market readiness (e.g. partners, sales, launch plan, training, support, etc.). We will address this as part of adapting their product roadmap and release plans.
All the best,
~ ellen
-
- -1
-
-
written by MadisonAgileBA, June 25, 2010
IMO, the weakness of Scrum is that it does not mandate automated testing (functional or unit), and without that, the problems of impact analysis and changes that affect previous sprints become very real. Early adopters knew this but the early majority (now adopting agile, usually Scrum) don't always, and it's like leaving out a load-bearing wall. (I've written about this--is linking to my blog acceptable in this community?)
IMO, the inherent weakness of Waterfall is the estimation problem. Early estimates just aren't accurate enough (and never will be), and regardless of mandates and commitments, something has to give. Because developers are highly utilized and expensive, there's not much slack in schedules and budgets. So the variability wants to be in scope. Scrum handles that variability extremely well, both in terms of detecting the deviation from initial plan early, and providing a mechanism for dealing with it. In Waterfall, detection comes later, and late scope reductions leave a lot of scrap. Or testing time gets slashed.
I agree with Alex about the culture. Scrum turns on the lights and exposes a lot of self-defeating behavior. What does the organization then do? If Agile proves to be to software-intensive businesses what Lean was/is to manufacturers, is the culture worth killing the company? To the people who benefit from the present culture, I guess it is sometimes.
Larman and Vodde have written a lot about how to scale Lean/Agile.
Having worked in both (as developer and BA) I've concluded that Waterfall has some irremediable flaws, while Agile (scrum+automated tests) does not. Both can be done badly (and are, now that Agile has reached the early majority), but waterfall is much less forgiving. That said, agilistas can learn a lot from good non-programmer practitioners, particularly BAs (especially those with good facilitative skills) and QA people in strong waterfall shops.
P.S. As far as the Terms of Usage goes, the right to "change or modify" my comments troubles me. But I'm assuming this power will only be used for good...
-
- +0
-
-
written by laith_ob, June 28, 2010
-
- +0
-
-
written by Colin101, July 25, 2010
Take the scenario where, 12 months after successful delivery, changes are required to the application. As the BA I would want to confirm the current state with the Business Owner before working on the new requirements and process.
Which of the following options do you think would provide the best outcome?
•Option 1 - Print off the appropriate waterfall project documentation (Requirements, Business Process, Use Cases) and review with the Business Owner.
•Option 2 - Print off the C++ code and review with the Business Owner.
-
- +0
-
-
Click Here to login or create a free account.
I've worked on many projects, large and small, using both waterfall, scrum and other agile techniques. I have become vary wary of a number of the agile techniques, particularly scrum and xp, for a number of reasons:
Poor Traceability - Scrum and XP tend to rely on user stories which are rarely maintained after their sprint has been completed. It seems common for the user stories to quickly become out of date and disconnected from the business/user objectives that spawned them or the code that was built based on them.
Impact Analysis - The way in which user stories are written, and again because they are rarely maintained, it becomes extremely difficult to do any requirements change impact analysis based on the documentation. The developers simply say "Well we'll apply the change and see how many unit tests break". This is just not acceptable in many environments.
Reliance on Strong Developer Skills - I was a code cutter for 20 years so I know a thing or two about development and developer teams. From what I've seen, the success of a project using agile approaches depends very heavily upon having a strongly skilled dev team. In my experience, if you have a dev team with one really strong guru on it then you're doing ok; if you have two or more then you're extremely fortunate. Agile relies on most of the team being very strong and places a very high-work load on the dev team lead if he/she does not have a strong team which is more often the case.
Don't get me wrong, I am not completely anti-agile. I have really enjoyed using it in light-weight, dynamic environments where the sponsor is keen to get rapid results, has an appetite for higher risk and couldn't give a toss about the documentation. It just seems to me that there is a fairly small box surrounding the projects for which agile is the optimal choice.
Regards,
David.