In these series of videos, Dr. Kevin Thompson compares and contrasts Agile projects with Waterfall projects and shows the affects of each when facing uncertainty. Kevin conducts a methodology experiment and shows why Agile projects succeed when others fail. All estimates are subject to uncertainty, and project schedules are no exception. A schedule consists of a set of tasks, which are executed at times dictated by dependencies and resources. The simplest schedule, consists of a set of tasks that are executed one after the other. The schedule for a project contains uncertainty because the estimated effort or duration of each task has some uncertainty associated with it. We would really like to know exactly how long a task will take. If we can’t know that, we would at least like to know how much uncertainty is associated with the task. Unfortunately, we will never know the first, and usually will never know the second, either. (The exception to the latter rule is for tasks that are repeated, identically, enough times for us to collect meaningful statistics about them.) Read the entire article.

Integrating Waterfall

by Shayan Alam, PMP

Waterfall and Agile/Scrum development methodologies are widely used by all organizations and are individually considered a proven approach for development. However, challenges arise as these two methodologies merge and clash. Here are a few key tips to help integrate both methodologies into your development organization. Let’s first discuss each methodology and its unique characteristics and assumptions.

The waterfall software development life cycle methodology believes in getting everyone together and involved early in the design process. The design process is longer and iterative as the team steps through the high level requirements, conceptual approach, solutions design, preliminary design and critical design. This assumes little will be left for discovery through the development and testing phases. Generally, waterfall has worked effectively for certain types of products – large, enterprise-wide development efforts where the user is being led through a standardized process.

However, Agile/Scrum is meant for a more volatile world and provides an iterative approach. For example, in the mobile applications space, the landscape is constantly shifting as new phones, new operating systems, and new technology to deliver data compete to get the user to interact in as many ways as possible. Short iterative development allows for an “open” mind for discovery since less time is invested upfront. In this case, discovery involves anything from functional flaws to ineffective user flows to the concept being deemed a bad idea altogether.

The fundamental difference between the two is Agile/Scrum assumes there will be flaws and therefore jumps into the coding to expose these. Therefore the success of the development team is driven on its ability to adapt and react quickly. Waterfall, instead, takes early precautions to mitigate any flaws.

This obviously causes a clash between development teams practicing each of the development methodologies. But certain steps can be taken to show the development team the advantages of the other’s methodology and ideally bring a team together.

5 Tips to integrating agile development groups with waterfall development groups

Trying to introduce agile as iterative waterfall will not work

Some organizations think they can be more “agile” by doing waterfall in smaller iterations. The problem is the timeline is tough to compress when fully vetted artifacts are expected after each round of reviews. There is too much overhead with all of the document creation which detracts from the amount of time left for coding. Agile is about streamlining processes not compressing them.

Development / QA can be iterative while being bookended by design and integration

One transition strategy is to employ agile in the development and QA cycles. Smaller scoped development cycles followed by QA. This way the customer sees the evolution of the application and can comment along the way. The design is properly vetted at the beginning and ample time is allotted for integration at the end.

Watch out for scope creep

A project manager’s challenge in working in a fast-paced “can-do” development team is managing scope creep. Since changes can be implemented quickly, anything and everything seems possible. So the distinction must be made and managed between what is considered a fix versus what is considered a change so that sprints are tight and marching towards the agreed-upon end product.

Play nice with QA

QA is always burdened as a release approaches, their schedule’s usually backed up against a wall. In waterfall, QA expects tight use cases to derive their test cases. So in the agile world, they get code thrown over the wall. That is why in agile teams, sometimes developers rotate into the QA role and become part of the solution from the beginning.

Be mindful of the end user

Since at the end of each sprint a fully functional application is delivered, it is very tempting to release it. This can be very annoying to users if this requires a frequent patch or upgrade. It makes the user wonder whether a polished product is ever in the horizon. If the upgrades are seamless, it may be a hassle to keep up with the new changes. Therefore a published release schedule or roadmap keeps the user in the loop. Major releases semi-annually and/or functional releases quarterly are recommended.

If you would like more information on this topic, send an email to info@cprime.com. We welcome your questions, comments and feedback.

How Uncertainty Works

All estimates are subject to uncertainty, and project schedules are no exception. A schedule consists of a set of tasks, which are executed at times dictated by dependencies and resources. The simplest schedule, consists of a set of tasks that are executed one after the other, and we’ll look more at this case below.

The schedule for a project contains uncertainty because the estimated effort or duration of each task has some uncertainty associated with it. We would really like to know exactly how long a task will take. If we can’t know that, we would at least like to know how much uncertainty is associated with the task. Unfortunately, we will never know the first, and usually will never know the second, either. (The exception to the latter rule is for tasks that are repeated, identically, enough times for us to collect meaningful statistics about them.)

In this article, we will look at uncertainty: Why it exists, how it behaves, how it accumulates, how to reduce it, and how to cope with it.

Why Uncertainty Exists

Suppose we are estimating the effort required to remodel a house. We will start by breaking down the project “Remodel House” into a few smaller steps, namely

Remodel Kitchen
Remodel Bedroom
Remodel Living Room

We want to estimate the effort required for each of these steps, such as “Remodel Bedroom.” Unfortunately, our estimate will not be exact. Estimates differ from reality because of uncertainties, which arise in many ways

Incomplete Understanding of Scope

We may not have accounted for all the requirements. Do we need to replace the baseboards? If we didn’t think about the baseboards, our concept of scope is missing an important element, and our estimate will not include the work to replace them.

Incomplete Understanding of Work per Scope

Perhaps we did include baseboard replacement in scope, but we assumed the effort involved was limited to nailing the new ones in position. Unfortunately, we didn’t account for the work required to measure and cut the baseboards to the right size, so even though the scope was right, the effort estimate will be too low.

Imperfect Understanding of Known Work

Even if we did remember all of the work that needs to be done for the baseboards, and estimate accordingly, our estimates may be off because some of the boards split when nailed. We will either have to replace those baseboards, or drill them to avoid splitting when we nail them. Either way, the work will increase beyond our estimate.

Inability to Forecast the Unexpected

What happens if the paint we need is out of stock, or someone delivers the wrong baseboards? These external events are unpredictable, and disrupt our schedule.

How Uncertainty Behaves

Most people have an intuitive feeling that tasks are more likely to require more effort than planned, rather than less. This feeling is correct, for two reasons.

First, we are likely to omit scope or tasks that contribute to the work, and so underestimate the effort. This is obvious, and we reviewed some examples above.

Second, there is more room, in a mathematical sense, for work to grow beyond expectation than to shrink below expectation. This may be less obvious, but think about the work required for Remodel Bedroom. Assume we estimate this work at three days. The actual time may be more than three days over this estimate, but cannot be more than three days under the estimate!

In mathematical terms, we cannot estimate a task as requiring “X plus or minus Y days,” because the estimate becomes meaningless if Y is greater than X.

What we can do is replace the concept of an increment of uncertainty with that of an uncertainty factor, F. This means that we think that X is the most likely duration, but the range of values is between X divided by F, and X times F.

For example, suppose we estimate “Paint Bedroom” at 3 days, with an uncertainty factor of 2.

The most likely case is 3 days.
The best case is 1.5 days, which is 1.5 days under the estimate.
The worst case is 6 days, which is 3 days over the estimate.

The real behavior of uncertainty is more complex than this simple model. (More sophisticated models rely on lognormal probability distributions and Monte Carlo methods.) However, our concept of an uncertainty factor is a convenient way to describe the most significant behavior of uncertainty, and we will continue with it.

How Uncertainty Accumulates

If errors were uniformly distributed above and below the expected values, they would tend to cancel out, on average, for a large set of tasks. As we’ll see, this is not the case.

Suppose we have a project containing 10 tasks, to be done one at a time, and each one is expected to take 10 working days. The naïve estimate for the project schedule is 100 working days for all tasks. The real schedule will deviate from the expectation, due to uncertainty.

Now we will assume that each task has an associated uncertainty factor of two. In the worst case, every task would take twice as long as expected, and the project would take 200 working days to complete.

The worst case isn’t very likely, so let’s consider a more typical case, where half of the tasks are under the estimate by the uncertainty factor, while half are over

The half that were under estimate take 5 days each (under by 5), while the half that are over estimate take 20 days (over by 15). The total time for all tasks is then 125 days.

Our typical case isn’t as bad as the worst case, but it exceeds the naïve schedule by 25% (25 days). This behavior is common, and it occurs because tasks can be over their estimates by more than they can be under. More realistic calculations, which rely on lognormal probability distributions instead of our simple uncertainty factor, are even more pessimistic. The long tail of the lognormal distribution has no upper bound, and tells us that some projects will never complete.

How to Reduce Uncertainty

While we cannot eliminate uncertainty when estimating work, we can take some steps to reduce it. One way to reduce uncertainty is to reduce the size of the thing to be estimated. The fewer the elements are that must be considered when producing an estimate, the more reliable the estimate is likely to be.

For example, the process of remodeling a bedroom contains a number of steps. If we estimate “Remodel Bedroom” directly, we may not think of all of the issues involved, and our estimate may be uncertain by a factor of three. Painting the bedroom, however, is a much smaller task, and has fewer elements that we may leave out of our estimate, so our estimate might be uncertain by a factor of two.

The obvious strategy for reducing uncertainty is to break large specifications or work items into smaller pieces. Thus we might break down “Remodel Bedroom” into four smaller tasks:

Remove old carpet
Paint room
Cut new carpet to fit
Install new carpet

Now we can produce an estimate for each of the smaller tasks. When we add these together, we will have an estimate for the bedroom remodeling, which is likely to be better than what we would have produced if we had not broken the work into smaller pieces.

The strategy of decreasing the “granularity” (size or level of detail) of items to be estimated improves accuracy, but has limitations. It can produce more items than we have the time to analyze, and thus delay the project completion. Also, there is no point in reducing the size below a level where the relative uncertainty does not improve. The important thing is to pick a granularity that (1) enables a tolerable level of uncertainty, and (2) produces a set of things to estimate that is small enough to be practical.

How to Cope with Uncertainty

Once we have reduced uncertainty to a practical minimum, the only other thing we can do is to take the remaining uncertainty into account in our process. We’ll look at strategies suited for projects that are subject to different kinds of constraints below. (For simplicity, we’ll assume that resources are fixed, since the ability to add resources does not vary in a meaningful way between the different scenarios. Similarly, we also assume that scope is well-enough controlled to prevent scope creep.)

Fixed Schedule, Fixed Scope

The first thing to understand about this set of constraints is that success is not always possible. If scope is truly fixed, and schedule is subject to uncertainty, then we have already seen that extreme cases will break any schedule.

These projects are planned with uncertainty in mind, by adding enough buffer time into the schedule to handle a reasonable level of uncertainty (for example, allocate 30% of the schedule for this purpose). This approach works well in situations where uncertainty is small, such as for repeating processes (e.g., laying carpet, or painting houses).

Fixed Schedule, Adjustable Scope

Many agile project-management frameworks handle uncertainty by committing to the only thing that can truly be controlled, which is the schedule, and adjusting the scope as required to meet the schedule. This strategy is particularly useful in high-uncertainty environments, where estimation is known to be inaccurate, and where scope is not well-understood and may change frequently.

The Scrum framework handles this situation effectively. It requires careful planning, but in a way that handles high uncertainty gracefully. Scrum projects work in short cycles to deliver modest increments of scope quickly, and to allow for frequent changes in scope and priority. Within each cycle, scope is adjusted as necessary in order to guarantee that the schedule is met.

No Schedule, Unknown Scope

Uncertainty is greatest when the scope is not known prior to the start of execution. This is the case for reactive organizations, such as Customer Support groups, which receive urgent requests that must be handled quickly, but which cannot be scheduled or planned in any meaningful way.

Another agile process, Kanban, is useful for this scenario. Kanban processes re-prioritize requests daily, and throttle (control) the flow of work by limiting simultaneous work-in-progress to a specified number (e.g., up to three concurrent requests can be handled by the staff).

Conclusion

Uncertainty cannot be eliminated by any estimation methods. It arises partly because of imperfect knowledge of what to do and how long it should take, and partly because of unpredictable events. The nature of task estimates is such that uncertainty biases deviations up, on average, relative to expected values. Again, on average, these upward biases accumulate even when as many tasks are under estimate as over, lengthening the schedule beyond the sum of expected task durations.

Reducing scope helps to reduce uncertainty, but only to a point. When uncertainty has been reduced as much as practical, the next step is to design the process to cope with uncertainty. We have reviewed three strategies for handling uncertainty:

For fixed-schedule and fixed-scope projects, add buffer time in the schedule. This works for low-uncertainty projects, especially those that repeat the same type of work many times.
For fixed-schedule projects, use an agile process such as Scrum, and adjust scope in a planned way to meet the schedule. This is an effective way to conduct a project when estimates are poor, and scope is poorly-defined and changes frequently, while still allowing for planning and a useful degree of predictability.
For unscheduled projects with unknown scope, uncertainty is very high, and planning is not possible. In this case, a strategy such as Kanban, which focuses on constraining work-in-progress, is effective.

What Is Scrum?

The term comes from rugby, where a “scrum” is used to restart the game after an event that causes play to stop. Each opposing team forms into a human wall three players deep, pushing against the other team to kick the ball out to their side. It’s the ultimate in teamwork and strength. Taking the analogy to software development, Scrum is based on multiple small teams working in an intensive and interdependent manner to deliver a piece of software.

The Scrum process flow is structured in cycles of work called Sprints. A Sprint is usually two to four weeks long, and is similar to an iteration in Rational Unified Process (RUP). At the start of each Sprint, teams pick features from a prioritized list of customer requirements, called user stories, so that the features that are developed first are the most important according to the customer. At the end of each sprint, a working “potentially shippable” product is delivered.

The full Scrum team has 7 members (+/- 2), including the Product Owner, the ScrumMaster, and the Scrum core development team. As the projects increase in size, the number of Scrum teams also increases. The fundamental components of Scrum are Roles, Ceremonies, and Artifacts. For the purposes of this article, we’ll forego further details about these Scrum concepts.

Scrum and Classic Project Management

Is Scrum compatible with classic project management as defined by the PMBOK® (Project Management Body of Knowledge by the Project Management Institute)?

The answer is yes, because Scrum is a process framework and is not really comparable to the PMBOK®, which seeks to standardize project management best practices. Scrum is not only compatible with the PMBOK®, it can be complementary.

Being a ScrumMaster is also not unlike being a project manager, and the two roles can even be shared by one person. Like any good project manager, a ScrumMaster facilitates, coaches, mentors, removes obstacles, communicates, and protects the team.

It may even be that as a project manager, you are unknowingly practicing Scrum techniques. Symptoms of Scrum-like behavior include:

Surrounding yourself with a highly-specialized and high-producing team who share commitment and trust;
Assessing progress on a frequent basis (optimally daily);
Reviewing requirements frequently, and reprioritizing if necessary (optimally monthly);
Identifying doable short-term goals with your team and showing accomplishment frequently (every 2-4 weeks);
Allowing experienced team members to assign tasks to themselves because they know what is needed to get the job done;
Bubbling up the right amount of information to stakeholders through visible and effective communication.

However, each organization adopts Scrum differently, and so the implementations of Scrum can vary greatly. Some “Scrummified” organizations have PMOs, some do not. As you learn about Scrum and experiment with it, you will begin to see how the entire organization might have to go through a mindset change to use Scrum fully and correctly. PMOs might have to examine their charter and make modifications to work with less rigid Scrum processes. In some organizations, it could be analogous to the change that had to happen when the move to project-based work was first made.

How to Start Scrumming

By now you are probably getting the idea that Scrum is definitely not a slam-dunk. Most companies tend to test Scrum with a trial project and leave the rest of the company using existing methods until the results are proven.

Here are some suggested steps to follow if you are thinking of implementing Scrum for the first time.

Find an executive sponsor in your organization who will support you and your Scrum endeavors (this point cannot be overemphasized).
Analyze how and if Scrum fits into your current environment.
Find a test project that does not have a major business impact but is still important to the organization.
Find a team of like-minded people who want to make Scrum work.
Provide training for the ScrumMaster, Product Owner, and Team Members. All of the team members could attend one course together so that they understand everyone’s role.
Hire an experienced ScrumMaster who will drive the project and mentor the team, especially the new ScrumMaster.

Getting Certified in Scrum

If you are interested in gaining more expertise in Scrum, the first step is to take a Certified ScrumMaster (CSM) or Certified Scrum Product Owner (CSPO) course. Unlike other certifications, the CSM or CSPO does not qualify you as an expert. It does mean that you have been trained in what a CSM or CSPO is supposed to do. The next step in Scrum certification is Certified Scrum Practitioner (CSP), which requires applicants to be an active CSM or CSPO and show one year of hands-on Scrum experience. All Scrum Certifications are for two years.

You will find more information about Scrum on these websites:

http://www.scrumalliance.org/ - Scrum Alliance. Scrum Certification body.
http://www.agilealliance.org/ - Agile Alliance. Has information on Scrum.
http://www.apln.org/ - Agile Project Leadership Network. Has information on Scrum.

The Future of Scrum

It is not yet possible to predict where the Scrum movement is going to end up. Is Scrum going to become just another entry in the already crowded field of Agile frameworks, like Lean Development and Extreme Programming (XP)? Or is it going to gain more momentum as larger organizations move towards a more “Scrummified” model? Of course, Scrum is not the only way to run projects, but it is certainly a burgeoning movement that has gained more publicity than most other Software Development methodologies.

Certainly Scrum has not worked for everybody. There have been classic failures of Scrum, but there have also been failures with waterfall, RUP, XP, and any of the other development methodologies around today. Probably the best advice is to be flexible when considering which framework to use. Just like you don’t wear the same clothes to work as you would to a football game or to a wedding, every technology project will be different and different frameworks and processes can be applied depending on the need for speed, reliability, profitability, or usability.

In fact, research is showing that the success of a methodology may lie more in the execution than the underlying principles. The more maturity and experience team members have, the less rigid the direction may need to be. So just like in rugby, if you are going to Scrum, make sure you Scrum with your eyes open and a good team around you.

Have a comment about the article you just read? Interested in getting more information on how to implement Scrum on your project? Send an email to crystal.lee@cprime.com. We welcome your questions, comments and feedback.

The Benefits of Scrum

Different stakeholders want different things from a software development process.

Developers want to write code, not documents.
Quality Assurance engineers want to create test plans that ensure product quality, and have high-quality code to test.
Project Managers want a process that is easy to plan, execute, and track.
Product Managers want features implemented quickly, with no bugs.
Services and Support personnel want to know exactly what is in all product releases, and have a reliable means to satisfy customer requests for bug fixes and enhancements.
Sales personnel want to know what is “in the pipeline” for future releases.
Customers want all of their feature requests and bug-fixes done quickly.
Executives, Program Managers, and PMO personnel want to know exactly what is happening, and what is planned to happen.
Everyone wants happy customers.

The list seems long, but the key points are few:

Team satisfaction and productivity are maximized when effort spent on non-deliverable items (e.g., internal documentation) is kept to a minimum.
Maximizing quality at each stage minimizes re-work at following stages, and maximizes product quality seen by customers.
Responsiveness is best achieved byfulfilling customer requests quickly.
Project status and plans should be visible to everyone who has an interest in them.

Thus the best real-world development process devotes as little effort as possible to artifacts the customer doesn’t value, provides relatively bug-free code at the start of testing, delivers all relevant information to everyone who needs it, and fulfills customer requests quickly.

It is no coincidence that Scrum was designed to satisfy these points.

How Scrum Provides its Benefits

The following sections describe how Scrum practices produce the desired benefits.

Team Satisfaction and Productivity

The “team” consists of the development and Quality Assurance engineers who do the hands-on work of creating a high-quality product. Team members generally find their greatest satisfaction when they can do work that is rewarding.

For developers, this means designing and writing computer software.
For QA engineers, this means defining the exact criteria for success through the test cases they develop.
For all team members, this means producing something they are proud of.

Productivity goes hand-in-hand with eliminating unnecessary work. Scrum addresses team satisfaction and productivity by emphasizing work that is valuable (as a deliverable) and rewarding (to the team), and de-emphasizing what is not (non-deliverable artifacts).

In practice, “non-deliverable artifacts” usually consist of internal documentation about product requirements and design, which customers do not see or value. Scrum projects do require some written documentation, but minimize it by relying as much as possible on real-time communication between people. Thus a Product Manager will write brief requirement descriptions (called “Stories”), and elaborate on the details as needed in discussions with team members.

The requirement for effective real-time communication means that one of the following must be true for all team members, Product Managers, and Project Managers (in order of decreasing desirability):

All are in the same building
All are in the same city
All are in time zones that overlap at least four hours per day
All are willing to spend hours per day outside normal working times (e.g., transoceanic teams).

The last three cases can only be made to work if real-time teleconference and Web-conference capabilities are available on demand.

Maximizing Quality

Teams implement Stories to the requirements, in a very literal sense: An implementation is not complete (a story is not “done”) unless it satisfies the requirements, as defined in the test cases. While test-driven development is not required for Scrum, test cases do define whether the requirements have been met, and no story is complete unless it passes all of its test cases. If bugs arise, developers fix them until the tests succeed.

This practice ensures that each Story implementation is bug-free, with respect to the requirements, at the time of its completion. It does not prevent regression bugs, so additional testing is necessary after all development is frozen. However, the quality of the product going into regression testing is higher than is the case for products going into the final test period for waterfall projects, and high quality ripples through all stages of the process.

Maximizing Responsiveness to Customers

Responsiveness means providing turnaround to customer requests in a manner that is consistent with customer priorities. Since instant turnaround is not possible, the next best thing is to respond quickly to high priorities, and less quickly to low priorities.

The only way to deliver any new feature or bug-fix quickly is to work in short development cycles, which is why the basic unit of Scrum development, the “Sprint,” is typically 2-4 weeks in length. Longer cycles, composed of two or more Sprints, are also common and often referred to as “Releases” (which is not a Scrum term).

Productivity and job satisfaction both require that people are productively employed, not sitting idle, which means that parallel work for team members is the norm. The two strategies for parallelizing work on a set of Stories are

Parallel work on serial Stories. The whole team collaborates on one Story, until completion, then begins work on the next.
Parallel work on parallel Stories. Each team member works on a different Story, until completion, then starts on another one.

Since Sprint lengths are “time boxed” (have rigidly-enforced durations), and unexpected problems can occur, it is often not possible to complete all work planned for a Sprint. For this reason, it is critically important that Story development be serialized as much as possible. This allows us to deliver, say, eight of ten planned Stories when only 80% of the expected work can be completed. In contrast, the parallel-Story strategy might produce no completed Stories at all in this case, and deliver zero value to customers.

The need to serialize Story development implies another important Scrum concept: Ranking. The set of Stories planned for a Sprint is called the Sprint Backlog, within which Stories are ranked (sequenced) for implementation. The Product Manager (say) is responsible for ranking the Stories, so that the most important ones are done first. (The Sprint Backlog is a subset of the larger Product Backlog, which contains all un-implemented requirements.)

The combination of short development cycles and ranking of requirements maximizes responsiveness to customer needs.

Providing Transparency

“Transparency” means that all steps, inputs, and outputs of the development process are visible-but to whom?

In the narrow sense, as typically described in books on Scrum, transparency applies to the internal membership of the team, the Scrum Master, and the Product Owner, as they need to know the status of the project every day. In this case, and for co-located teams, transparency may be provided by posting index cards or sticky notes with the current Story and task status, along with the current burndown chart, in a public location. The Scrum framework essentially guarantees this level of transparency.

(A “burndown chart” is a bar or line chart showing, each day, the amount of this Sprint’s planned work that remains to be done. The ideal progress is indicated by a diagonal line, trending down to zero on the last day, against which the actual state is compared.)

Transparency in the wider sense means that every stakeholder who has a need for project status information has immediate access it. “Status information” includes not only the status of the current Sprint, but the content of past Sprints or Releases, and the Product Backlog. The Scrum framework does not provide a standard practice to meet this need, but it provides excellent an excellent foundation for meeting it.

Transparency for stakeholders and distributed teams can be achieved via agile project-management applications (e.g., Rally or ScrumWorks), to which all team members and stakeholders are given access. These applications store all requirements and task definitions, track work status, and provide sophisticated reports. They enable distributed teams to collaborate, and allow stakeholders to query for the information they need, without adding a burden on the team or Scrum Master.

Conclusion

Scrum is designed to optimize team satisfaction and productivity, product quality, responsiveness to customers, and transparency for stakeholders. The key practices that enable these benefits include de-emphasizing work on non-deliverable items, implementing and finishing each Story in a Sprint Backlog in rank order, working in short Sprints of 2-4 weeks, and making past, present, and future project information available to all stakeholders.

When to Use Scrum for software projects?

By Kevin Thompson, Ph.D.

Scrum is a lightweight agile process framework used primarily for managing software development.

Scrum is:

Lightweight because it has few prescribed elements
- Three roles: Team, Scrum Master (often a Project Manager), Product Owner (often a Product Manager)
- Three meetings: Sprint Planning, Daily Scrum, Retrospective
- Three artifacts: Product Backlog, Sprint Backlog, Burndown chart
Agile because it maximizes responsiveness to changing customer needs
A process framework because it is not a process, but a collection of practices and concepts around which a process can be built

Scrum is often contrasted with the so-called “Waterfall” approach, which emphasizes up-front planning and scheduling of activities, followed by execution. Both approaches require careful planning, followed by execution and tracking, but the details of how these steps are accomplished are different.

Scrum

Scrum processes are cyclical, repeating every few weeks. Product Owners provide requirements, in the form of Stories (short narrative descriptions). The Team of developers and QA engineers implements the Stories in a Sprint of 2—4 weeks in length. During the Sprint, Team members work with Product Owners to refine and clarify requirements, to ensure proper implementation. Final requirements are defined by test cases created by QA engineers, and are used to validate each story to confirm that it is complete.

Stories are implemented in rank order, one at a time, to ensure that highest-priority requirements are implemented first. This serialization of feature development ensures that some useful features will be completed even if less work can be accomplished during a Sprint than expected.

Waterfall

Waterfall processes are linear. They assume the Project Management Institute’s definition of a project as a “temporary endeavor undertaking to create a unique product, service, or result.” Of course, one can repeat a particular Waterfall process to produce a cyclical “overprocess,” and this is common in the software industry, but a Waterfall process is not cyclical.

In a Waterfall process, the Project Manager works with stakeholders to elicit requirements, and creates a work breakdown structure (WBS) that defines tasks at a granularity suitable for estimation. The development-team members provide estimates for the work, and the Project Manager develops a schedule based on the work estimates, task dependencies, and resources. The project team then executes the work according to the schedule. The Project Manager monitors progress, facilitates problem resolution, and solicits scope or schedule changes as needed to meet the project objectives.

Why Choose Scrum versus Waterfall for Software Projects?

The two approaches make different assumptions about the priorities and practicalities of the work to be accomplished.

Waterfall Processes Assume or Require that

Success is defined by achieving the planned scope.
- Tightest constraint may be on scope or schedule
  - Sometimes schedule is extended to achieve scope
  - Sometimes scope is reduced to achieve schedule
Requirements are well-understood and will not change
- Change requests represent exceptions that must be handled by a change-request process
All steps are known and can be estimated with reasonable accuracy
Process is linear: Starts with requirements, leads to results, and stops
Some steps may involve long lead times, or lots of specialized resources
Incremental results (e.g, at 20% of scope) have little or no value

Scrum Projects Assume or Require that

Success is defined by responsiveness to customer requests
- Requires quick turnaround (2—4 week Sprints) for high-priority requests
- Tightest constraint is on schedule, to achieve quick turnaround
  - Scope is adjusted to fit schedule
Requirements change frequently, even from month to month
- Change is the norm, and requests are re-prioritized at Sprint boundaries
Work requires constant invention, so all steps are not known in advance, and estimates are not expected to be reliable
Process is cyclic: It repeats every Sprint, and planning for next Sprint overlaps with the work on the current Sprint
No steps involve long lead times or lots of specialized resources
Incremental results (e.g., at 20% of scope) have significant value

Few of the criteria individually identify which process is more appropriate for a project, but taken together, the decision is usually straightforward. Some examples include

Deploying an ERP application, such as SAP. The vendor has done this many times, has a process with all steps clearly defined and understood, and can proceed with a well-practiced waterfall process.
Creating custom reports for the ERP application. This is likely to be an iterative process, as reports evolve towards greater usefulness over time due to user feedback, and is well-suited to a Scrum process.

In general, if you have to figure out how to do a significant amount of the work in the project because you haven’t done it before, so you cannot estimate accurately, go with a Scrum process. If you’ve done it many times before, and know how to do it again, go with a waterfall process.

About the Author

Kevin Thompson, Ph.D., is a Certified Scrum Practitioner and Project Management Professional. His Scrum in Practice workshop through cPrime (www.cprime.com) trains teams, Program Managers, and PMO personnel on the nuts-and-bolts of how to implement Scrum for software development.

Project Management & Agile Development

5 Tips to integrating agile development groups with waterfall development groups

Other Frequently Viewed Articles

How Uncertainty Works

Why Uncertainty Exists

Incomplete Understanding of Scope

Incomplete Understanding of Work per Scope

Imperfect Understanding of Known Work

Inability to Forecast the Unexpected

How Uncertainty Behaves

How Uncertainty Accumulates

How to Reduce Uncertainty

How to Cope with Uncertainty

Fixed Schedule, Fixed Scope

Fixed Schedule, Adjustable Scope

No Schedule, Unknown Scope

Conclusion

Other Frequently Viewed Articles

Do you know what a Scrum is? Wondering if you should try Scrum on your next project?

What Is Scrum?

Scrum and Classic Project Management

How to Start Scrumming

Getting Certified in Scrum

The Future of Scrum

Other Frequently Viewed Articles

The Benefits of Scrum

How Scrum Provides its Benefits

Team Satisfaction and Productivity

Maximizing Quality

Maximizing Responsiveness to Customers

Providing Transparency

Conclusion

Other Frequently Viewed Articles

When to Use Scrum for software projects?

By Kevin Thompson, Ph.D.

Scrum

Waterfall

Why Choose Scrum versus Waterfall for Software Projects?

About the Author

Other Frequently Viewed Articles