Why Agile Sprints Are Not Tiny Waterfalls

One of the first questions that comes up when a team is introduced to scrum is the difference between a sprint and a waterfall.

Traditional waterfall development happens from beginning to end in a sequence that’s easy to understand, and at first glance, agile sprints appear as if they’re simply shorter versions of the same workflow.

There are comparisons, but this kind of reductionism overlooks many of the true advantages of agile development.

Respecting the differences can help your team–and people watching from outside of your team–get a better understanding of agile and how it works.

What is Waterfall?

A waterfall development process assumes that every aspect of the project, from identifying the customer to developing and delivering the final product, happens in sequence.

That sequence is well-defined, logical and repeatable. The orderliness of waterfall is one of the reasons that it’s so popular.

First comes customer research and product design. Then designs are handed off to engineering and development begins. After that, what’s been built is tested, and engineering iterates on the product until it is an exact match for the product specifications identified in the design phase. Finally, the product is delivered to the customer and the whole process starts again.

This is a very effective approach when you’re in an industry where requirements don’t often change, the customer base is stable and technology is relatively consistent.

These conditions exist in many industries. For example, the automotive industry can rely on a steady stream of customers, a long development cycle and timeframes of months or years between concepts and final delivery. At the end of that time, the market is still there, and customer expectations are still essentially the same.

Waterfall is also appropriate for some high tech companies. In the microchip industry the typical timeframe between chip design and actual delivery can be as long as four years. The commoditized nature of chips and the slow and steady pace of technology changes in this industry make waterfall development an ideal approach.

In the appropriate industry, there are a number of advantages to waterfall.

Every team has time set aside to do the work it needs to do. The operating instructions for waterfall come in the form of a well-defined product requirements document, which serves as a reference for all of development and all of quality assurance.

And because everything is specified up front, it’s easy to measure how well the team is moving forward towards achieving the final goal.

What is a Sprint?

Sprints are a way of dividing up the process of agile project management. They are generally sized in a range of weeks, and the length is consistent from one sprint to the next.

While a team may be working on completely unrelated stories from one sprint to the next, the stories defined and prioritized within a single sprint are considered sacred. This gives the product owner regular opportunities to adjust development priorities while still affording engineers the focused time they need to dig into a set of stories with clear acceptance criteria, secure in the knowledge that priorities will not shift and scope will not creep from outside.

Each team decides for itself just how long a sprint will be. The length of the sprint depends on both the types of stories the team is working on and the expectations of the industry.

In order to make the results from one sprint comparable to others for the sake of tracking velocity and developing a point estimation scale, teams should keep sprint lengths consistent unless they discover a real business need that forces a change.

A sprint starts with a planning meeting in which the product owners present the stories that should establish the sprint’s theme, and the engineers estimate the amount of effort required to complete each story. Stories are written as features that can be completed and shipped within a single sprint.

Once the sprint is finished, the product should be in a shippable state, with any completed stories integrated. The product owner has final say over whether the results of the sprint are actually released.

During a sprint the entire team meets daily for a 15-minute standup. At this ritual, all the developers report on what they did since the previous standup, what they plan to do until the next standup and whether there’s anything standing in the way of their progress. Stories that have been completed are marked as done, and new stories are selected from the top of the prioritized backlog.

The order of the backlog is the responsibility of the product owner and may be adjusted constantly during a sprint, although the actual stories and acceptance criteria may not be altered until the next sprint planning meeting.

At the end of a sprint there is a demo of the completed product with the new features, so the product owner can accept or reject the work. Any stories that are rejected may either be added back to the backlog, put in an icebox to be restarted in a different sprint, or rewritten by the product owner to reflect changing acceptance criteria that came up during the course of the sprint. Of course, if a story’s acceptance criteria change, the team will need to re-estimate the effort required to complete it at the next sprint planning meeting.

The sprint concludes with a retrospective, during which the team has the opportunity to discuss what went well during the previous sprint, what didn’t go so well, and what the team learned that can help it improve in future sprints. The team may also propose and discuss process changes, which should be agreed to at the next sprint planning meeting.

How Are Sprints Like Waterfall?

If you come from a waterfall background, it’s easy to look at the structure of a sprint and equate it with a small waterfall.

After all, each sprint starts with a set of product requirements that have been detailed out with acceptance criteria, and it ends with a finished product that is ready to ship.

In both waterfall and agile sprints, the product owner is the one who establishes the requirements for the product. The process of creating and designing new features happens before the team starts working, and the acceptance criteria are used to judge whether the work performed has been done according to expectations. Generally the stories for one sprint are written and designed while the previous sprint is still in progress.

The work done during a sprint or a waterfall needs to go through development and quality assurance before it is considered done, and it then must be presented to the product owner for acceptance or rejection. If the work is not accepted, it needs to cycle back through development and QA again, unless design or requirements change.

And once a sprint or a waterfall is complete, the finished product may or may not be shipped. That decision still rests with the product owner.

How Are Sprints Different From Waterfall?

While waterfall allows the phases of product development to operate as isolated black boxes, sprints are short, transparent and iterative, and they emphasize collaboration at every opportunity.

The brevity and consistency of a sprint is just as important to an agile organization as the formality of the development cycle in a waterfall organization.

But for an industry that is subject to shifting customer and market expectations, the ability to pivot at the beginning of every sprint can make the difference between delivering real value and delivering something that nobody really wants anymore.

Engineering happens best when the engineers can work without being distracted by the turbulence of the marketplace, but real products need to address the desires of the customers no matter how frequently they change.

In a market that needs to respond quickly to shifting customer needs, the ability to work in brief, consistent, measurable sprints allows engineering to focus for a determined time period on solving a clearly defined and prioritized set of problems.

In a waterfall organization, the work of the product owners, designers, developers and QA engineers can be done in complete isolation. That way each professional group can operate according to its own set of standards, as long as it delivers the intended output at the end of its working cycle.

But such a measured approach is only practical when the timeframes are long and the final product is predictable.

Sprints expose the workings of everyone on the team, making it easier for everyone to adjust their efforts and expectations as the work progresses. When the market is unpredictable, and the timeframe for delivery is urgent, this degree of visibility helps everyone on the team adapt and adjust consistently.

For people used to the isolation and exclusivity of specialization, the transparency of sprints can feel unfamiliar at first. But with that transparency comes the opportunity to expose and respond to problems quickly and efficiently, whether they relate to product development or employee satisfaction.

Waterfall assumes the professionalism of everyone on the team and allows that faith to drive progress within the groups while they are working on their part of the product. Because the only required interactions happen during the exchange of requirements, the product owners are free to work according to their own processes independent of those used by the engineering team. Most waterfall organizations do provide for regular updates and reports across groups to assure that progress is being made, but it is up to each organization to manage its internal processes. And since the timeframes in waterfall tend to be longer, these processes rarely shift once established.

The iterative nature of regular sprints encourages a team to to come together frequently to learn and improve their processes. As a team gets more experience delivering completed stories, it gets better at estimating the effort how long a given feature will take to implement correctly.

Agile organizations reflect regularly on what could be improved about their processes, and they are not afraid to try something different, secure in the knowledge that any change may only be in effect for the length of the next sprint.

What Approach is Best for Your Company?

There is no one answer to this question.

In a predictable market, the stability of waterfall makes it a viable solution.

In a more chaotic market, the responsiveness of an agile approach may make the best use of the available resources.

And these are only two possible options in a range of possible organizational choices.

The one thing that doesn’t seem to work is trying to blend the approaches.

Picking and choosing this part of waterfall and that part of agile can lead to an inconsistent “Frankenprocess” that leaves everyone confused and dissatisfied.

For example, while waterfall is driven from the top down, agile encourages every member of the team to expose what they learned in a sprint, allowing other team members to apply the new shared knowledge in future sprints. Team members may find it frustrating if they are encouraged to behave as if they were in one type of organization, while simultaneously being expected to conform to the structure of a different type.

Waterfall and agile each offer internally consistent sets of checks and balances that only work when they are part of a planned and integrated approach.

The choice your team makes involves both a sense of the market and a management philosophy. Every company needs to decide for itself what process makes the most sense–and commit.

Frequently Asked Questions on Agile Sprints and Tiny Waterfalls