Chris Burns / Culture Development / December 8th, 2014

Helping Your Scrum Team Avoid a Waterfall Mentality

We’ve been beating the Agile drum for a while now. Though agile has been used in other industries for a while, it’s new to the digital agency world. We’ve all agreed that being agile/lean/scrummy is the best way to operate, but any agile team knows that actually staying agile is a constant challenge.

Despite the value that many teams see in agile and scrum, they walk a thin line between being agile and merely appearing to be agile. No matter how much we might wish they weren’t, traditional waterfall processes are in our blood, and it can be easy for an agile team to slide down a waterfall without realizing it.

Waterfall World

The dubious efficiency of the assembly line.
The dubious efficiency of the assembly line.

Many of the processes and principles we employ for production, design and building have their roots in the Industrial Revolution. Industrialization taught us to think about something, design a way to make it repeatable, use machines to do the heavy-lifting, and then hand the non-automated parts to someone to do one piece over and over. It’s a pretty simple concept and has helped humanity achieve incredible results. Non-tech folks would call it the assembly line, but anyone in the tech world will call it waterfall.

Classic aspects of waterfall production:

  • The full project is designed up front
  • Once something is done, you don’t revisit it
  • Testing is left until the end
  • All work and decisions flow through the project manager
  • Value isn’t realized until the work is 100% complete

We’ve used these processes and techniques for nearly 300 years, building much of the modern world; we know they’ll still work today. But now that we’ve found a better way (agile/lean), we need to be conscious to avoid our old habits, no matter their eventual effectiveness.

Why the Slope is Slippery

Photo by wncoutdoors
Photo by wncoutdoors

Intellectually, I think we’re all on the agile/lean bandwagon. It makes sense, and many organizations have seen success with it. So we’re all quick to jump on. “Yep, I do lean manufacturing,” or “Yes, my whole organization is on Scrum.” Yes yes yes! But are you really?

Anyone who works in a lean fashion knows that staying agile is a struggle. Or they’re in denial. Yes, you’re doing some of the “agile-y” things, but that doesn’t mean you’re actually agile.

Here’s the problem: waterfall is inherently process oriented. One person does that so someone else can do this. But at its core, agile is more than a bunch of processes; it’s a set of values that can be applied to improve processes. The Agile Manifesto tells us:

Individuals and interactions over processes and tools

Here’s where most people fail to be truly agile – agile needs to be a mindset, and it’s in the mind where most people fail. Many team members may be religious about processes and ceremonies, but they think in ways that aren’t agile. It comes out in a person’s attitude; you might see it in your organization when someone says something like:

  • I’m just going to throw it over the fence to QA.
  • I just want a completed spec.
  • That’s not my job.
  • I don’t know how to do that.
  • I won’t start until that person finishes.

Those simply may be warning signs of a bad attitude or inflexibility, but it doesn’t sound all that agile to me.

watefall

OK,  I May Be Slightly Waterfall-y

In my last post, I warned agile teams about clinging tightly to their designated roles. I focused on Quality Assurance, but it’s easy for any team member to fall into a waterfall mentality when they only see themselves as a designer, developer or marketing person, rather than a team member.

I highlighted three points from The Scrum Guide that provide some guidance into the proper mental state for an agile team.

  • “Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.”
  • “Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.”
  • “Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”

Clinging to a role, title or skill is the easiest way for someone to revert to a waterfall mentality, even when technically operating in an agile fashion. No team member should ever say “That’s not my job.”

Responding to change over following a plan

In my experience, this is the other agile principle that can occasionally keep agile teams from being truly agile. Even working in short sprints, it can be easy to ignore problems that might derail the sprint.

Transparency is critical for any healthy agile team. Waterfall made it easy to mask problems or hide roadblocks; since everyone works in isolation, problems can delay development for days or weeks without ever being revealed. My team uses colorful burn-down charts and cumulative flow diagrams that are inherently geared to manage change so the entire team is aware of any change and can react appropriately, rather than blindly following the sprint plan.

Again, agile is all about working in the proper mindset. Without constant diligence and team accountability, it can be very easy for a team member – or any entire team – to backslide into a waterfall mentality without realizing it.

Now, Spread the Word

Have you run across these mindsets while being in the agile world? If so, how did you handle it? Share your thoughts in the comments below.

  • Robert C Hanley

    Sometimes things are just unavoidably linear though. Like I could write all the back-end functionality for a story but can’t connect it to the front-end until it exists, a front-end won’t exist until a design gets finished and approved.

    We can stay somewhat agile by jumping to a different story but at the end of the day isn’t the assembly line ultimately inescapable??

    • Christopher Burns

      Yes! I think what you described is very much in line with Agile. Just like you might have to write a DB query before the story can be QA’ed… technically it’s linear but I don’t think there’s any way around that. To me the problem would be if the front-end dev said, “I won’t start working on the UI until Bob is 100% done with the functionality”. Those things could be developed in tandem. In my analogy, the assembly line worker needs to put a tire on a rim before the next person will start putting the wheel on the car. There’s no opportunity to work in parallel. And worker #2 effectively will twiddle his thumbs while he waits for another wheel. As long as everyone is working at their peak efficiency (not jumping between multiple jobs at once) then you’ve got the makings of a great agile team and a great sprint.

      • http://352inc.com Lincoln Anderson

        As an addendum, the idea of the design getting “finished and approved” can be a huge sticking point. You have to set the expectation that the design is a medium-fidelity vision, and it has some things that will likely not change during the build-out (ie branding aesthetic), some things that will probably change a little as we use what we’re building (ie labels, form field types, layout tweaks), and some things that won’t change (the user story goal), and that’s expected. The team has to make the call that we’re “close enough to avoid too much risk in developing the wrong thing”, and yet not being perfectionists or nailing down a “final” design. That allows you to design a bit of a vision ahead-of-time, but also bypass most of the assembly line stuff. It allows you the freedom to make design decisions during development as they make sense for business reasons. I think that probably takes coaching with a new PO, and trust that “approval checkpoints” are not necessary if you’re communicating well.

  • http://352inc.com Lincoln Anderson

    I am so impressed with this guy. Keep the posts coming bro.