By M. David Green

Why Agile Sprints Are Not Tiny Waterfalls

By M. David Green

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.

  • Michael Glatter-Götz

    Thank you for this great overview, it really helped me to get a better understanding of agile/Sprints.

    We are a software development company and are mostly use the waterfall approach. What are your thoughts on this topics, should we decide to (partially) try out a Sprint based approach?

    * We would probably try out an agile approach with one team/product first. Do you have experience with only one team of a company doing Sprints, the others still doing waterfall?
    * We have flextime, meaning that employees can choose their working time freely. How do you handle the standup in such environments? In the middle of the day when (hopefully) most of the team members are in the office?

    • At our company stand ups occur during the start of our “core hours” period, during which everyone must be present. We also have work-from-home days, and in that case team members call in on a conference call.

    • rhpaiva

      Michael, applying Scrum to a small set of people involved in a project can actually be beneficial. If implemented by someone with experience in what and how to do, namely an experienced Scrum master, that grop can become an example for the other teams and generate energy to drive the other ones. But you must have someone who eats agil methodologies for breakfast. When applied incorrectly it might damage the culture of the company.

      Regarding to flex timetables, I suggest that the team choses a time when everyone must be present and available, like for example 3pm. For my team it was the perfect time for everyone to be present at the office after having their lunch time. Even for the ones who arrive later usually.

      The keyword in this process is commitment. Everyone in the team needs to be committed to what was agreed by the team.

  • Alan Stubbindeck

    I’ve been a CSM (Certified ScrumMaster) since October 2012, and one thing I’d like to share is that if your organization is thinking about adopting Scrum, beware the power-holders that are not 100% committed to the methodology. It’s extremely easy to turn the daily stand-up meeting into a daily email, it’s easy to ditch the retrospective and tack something on at the end of the planning meeting and so on. If you go to any formal Scrum training, they will tell you that if your company does not 100% adhere to the guidelines provided for Scrum, you’re not actually “doing Scrum”. Everyone’s corporate culture is different, but don’t be shocked if 100% adherence/acceptance eludes you at first. Just keep at it, promote the process as much as possible, crank out some great work in your first sprints, and navigate your company’s culture as best you can!

    • I think “pure” Scrum works in certain cases and needs to be adjusted in others.

      Our process is closer to something called WaterScrumFall, with more planning up front, followed by traditional Scrum development sprints. The focus on up-front planning occurs because we’re a consulting company, and as such we need to sell the client on a specific set of deliverables as described in a signed SOW.

      In short, I think people need to focus on making the process work for your specific needs and organization, with less emphasis on whether or not you’re doing “!00%” Scrum.

      It is, after all, an “agile” methodology and the guidelines are just that, guidelines.

  • Matt

    Great read. I worked in an agile environment and have since moved on to a place where we are still using waterfall. We have a team of four developers, four designers and two testers and still use a spreadsheet for scheduling.

    How did you guys make the leap into agile initially? I think we have a great case to separate one person from each specialism and create a sub team that works to agile. Is this what you guys did?

    I created my own presentation on how our company could utilise agile and it went down like a lead balloon (It was only given to the head of web dev, whereas the feeling for the rest of the team is we need agile however I haven’t been allowed to show the team the presentation).

    His concerns were that with the spreadsheet we can see easily into the future meaning we can give clients an accurate go live date, with agile we can’t.

    Any tips would be great! Thanks

  • Axel Vanhooren

    The sequence in a waterfall is well-defined and repeatable? .. Well, not that much. A methodology is not a procedure (as many Agilists seem to assume). It is always up to the analyst, designer and PM to define the steps. A methodology only suggest a sequence of steps. This is logical since every project is different. So, the executed project’s process is different as well.
    The sequence depicted by the waterfall (which is btw rather a misleading image) is not that sequential. Iterations are possible. For example, when during the design it is noticed that some issues remain unclear. Then some analysis activities have to be performed. So during the design phase of the project analysis activities are done. This isn’t a problem. We have to make the distinction between the intellectual level (for analysis and design), the activity level and the project phase level. The sequence may exist at the project phase level, but it doesn’t need to exist at the activity level.

    The waterfall isn’t always that ‘waterfall’ as we may think. ;-)

    Expectations change.. always. The required solution changes much lesser.
    In my experience, many changes aren’t changes. Let’s assume an analyst made a sloppy analysis. The problem or the situation is only partially understood. The design based on this analysis can’t be right. As a project progresses, the insight increases. The stakeholders or some members of the project team may become aware of an aspect of the product isn’t right. It must be changed. It’s a change. Well, it’s a change in requirements or in design. But the problem or environment didn’t change. It’s just a correction of a bad decision. That’s why more analysis and better analysis is so crucial. It serves to avoid designing wrong solutions or to solve wrong problems due to a too superficial insight. And real changes? Nobody can prevent them from happening. It’s not a problem. It’s part of the game.

Get the latest in Entrepreneur, once a week, for free.