http://en.wikipedia.org/wiki/Scrum_(software_development)
| Topics | Plan-Driven Principles | Agile Principles |
|---|---|---|
| Similarity between development and manufacturing | Both follow a defined process. | Development isn’t manufacturing; development creates the recipe for the product. |
| Process structure | Development is phase-based and sequential. | Development should beiterative and incremental. |
| Degree of process and product variability | Try to eliminate process and product variability. | Leverage variability throughinspection, adaptation, andtransparency. |
| Uncertainty management | Eliminate end uncertainty first, and then means uncertainty. | Reduce uncertainties simultaneously. |
| Decision making | Make each decision in its proper phase. | Keep options open. |
| Getting it right the first time | Assumes we have all of the correct information up front to create the requirements and plans. | We can’t get it right up front. |
| Exploration versus exploitation | Exploit what is currently known and predict what isn’t known. | Favor an adaptive,exploratory approach. |
| Change/emergence | Change is disruptive to plans and expensive, so it should be avoided. | Embrace change in an economically sensible way. |
| Predictive versus adaptive | The process is highly predictive. | Balance predictive up-front work with adaptive just-in-time work. |
| Assumptions (unvalidated knowledge) | The process is tolerant of long-lived assumptions. | Validate important assumptions fast. |
| Feedback | Critical learning occurs on one major analyze-design-code-test loop. | Leverage multiple concurrent learning loops. |
| Fast feedback | The process is tolerant of late learning. | Organize workflow for fast feedback. |
| Batch size (how much work is completed before the next activity can start) | Batches are large, frequently 100%—all before any. Economies of scale should apply. | Use smaller, economically sensible batch sizes. |
| Inventory/work in process (WIP) | Inventory isn’t part of the belief system so is not a focus. | Recognize inventory and manage it to achieve goodflow. |
| People versus work waste | Allocate people to achieve high levels of utilization. | Focus on idle work, not idle workers. |
| Cost of delay | Cost of delay is rarely considered. | Always consider cost of delay. |
| Conformance to plan | Conformance is considered a primary means of achieving a good result. | Adapt and replan rather than conform to a plan. |
| Progress | Demonstrate progress by progressing through stages or phases. | Measure progress by validating working assets. |
| Centricity | Process-centric—follow the process. | Value-centric—deliver the value. |
| Speed | Follow the process; do things right the first time and go fast. | Go fast but never hurry. |
| When we get high quality | Quality comes at the end, after an extensive test-and-fix phase. | Build quality in from the beginning. |
| Formality (ceremony) | Formality (well-defined procedures and checkpoints) is important to effective execution. | Employ minimally sufficientceremony. |
I have recently been asked for advice on how to compare Waterfall (WF) and Scrum. This is a hard question in some ways: the best way to compare will depend on the person you are talking to. Another problem is that few people do ‘pure’ waterfall in actual practice. And the variations of Waterfall are many.
Still here are some thoughts that occur to me. We think these statements often need explanation, but they can be useful as a start for a discussion, eg, ‘should we move from waterfall to Scrum?’
***
Scrum has a prioritized Product Backlog (mainly by Business Value), from which one could execute the Pareto Rule.
WF tends to assume the 100% – 100% rule. And tends to order the building of the product mainly by technical dependencies or by what the geeks want to do first.
Scrum uses adaptive planning.
WF tries to keep to the initial plan.
Scrum gets feedback from working software early (first sprint, in 2 weeks) and often (every sprint).
WF does not have working software until very late in the cycle.
WF assumes we know ‘everything’ upfront.
Scrum assumes there is lots we don’t know (yet), and focuses on maximizing learning throughout the project.
WF tries to minimize change (a change control board for any requirements changes, for example).
Scrum tries to maximize the benefits of good change (eg, learning), and minimize the negative impact of bad change.
Scrum assumes change is normal, and anyway much of it can’t be controlled usefully.
WF assumes change is bad and can be controlled (usually).
WF puts most responsibility on the PM.
Scrum puts most responsibility on the small dedicated Team.
(WF uses a diffuse work group, with only the PM with clear overall responsibility.)
WF assumes the PM should plan the work.
Scrum assumes it is best if the Team plans its own work and re-plans.
WF prefers ‘planning from the center’ (e.g., by the PM). And the workers just execute what they are given.
Scrum prefers more self-organization, and using the full ‘complex adaptive system’ (a tight thinking adaptive Team).
Scrum optimizes business value, time to market and quality.
WF optimizes conformance to schedule and budget.
WF’s typical problem is analysis paralysis and being late. Scrum addresses these.
People using Scrum often err in not thinking quite enough up-front….an easier problem to fix, we think.
When people do WF they typically are thinking: “If I just follow the process and the plan, all will be well.”
Scrum tries to force the Team to think for themselves, in their specific situation. Hence, it is a bare framework of things that are essential for every effort. Always other things, in addition to Scrum, must be done.
WF has weak controls (eg, conformance to schedule).
Scrum has strong and frequent controls (e.g., did you all get all those features done this past 2 weeks?)…which enables faster improvement.
Notes:
Unprofessional people often say they are doing ‘Scrum’. Above we are talking about vigorous professional Scrum, not ‘cowboy Scrum’ or ScrumButt.
Good people forced into WF typically use agile-scrum ideas to make it really work. Above we are talking about ‘true’ Waterfall. While ‘true’ Waterfall rarely exists, we think that one can still see that the ideas and practices of Waterfall, as much as they remain in real practice, impede progress compared to Agile.
Final comment: I am not convinced that these are all the statements one could make. Also, please don’t assume I have all the top 5 best comparison statements. Your feedback is very welcome.
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…
Great post, very good delineation between Waterfall and Scrum. Thanks.