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.
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
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.
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.