Expert product manager skillfully pressing all the right buttons

Everyone is doing Agile.

I dare you to find a company that doesn’t claim they are like totally cutting edge and stuff because they “do Agile”. That means stuff like stand-ups in the mornings and using words like “backlog” and “sprint”, and changing the name of the manager of the team to “Scrum Master”.

I’ll resist the urge to drill into into my pet peeves of “Scrum, but…”, “AgileFall” and other such atrocities in this post (I need stronger heartburn meds for that). I do, however, want to drill into the rationale companies have in their rush to do agile.

I’ll tell you why: most of them think it’s about speed. Agile gets you more, faster, bigger, and cheaper, right? Costs down, productivity up — all charts up and to the right! 📈

Not pictured: the part of this cow that generates things analogous to “Agile equals speed” -thinking.

Sorry, everyone. That’s a load of 💩.

Agile doesn’t make anyone work faster nor deliver more things at a higher pace. When things are predictable (spoiler alert: they never are), waterfall is actually way faster and more efficient.

What’s the point, then? I’ll give you a hint: it’s in the name.

Agility.

Why Agility Actually Matters?

Let’s get one thing clear: the only constant thing is change.

These things happen literally all of the time.

Waterfall and other industrial era conveyor belt methodologies try to manage out this chaos. In their world, more planning = less change.

This is where we get to the heart of Agile: It leans into the pain of change. Instead of trying to remove change, it embraces it. The core takeaway of Agile is adapting to change. Making decisions when they count the most and when you’re best equipped to make them: as late as possible.

It’s not about running faster, it’s about walking a shorter distance.

If you think speed is more important than maneuverability, please don’t offer me a ride in your car. I’d rather get there safe & sound on my own time.

The road to glory. I guarantee you don’t want to just lean on the gas pedal on this one.

Agile-hostile Environments

Agile is a tough sell. It requires incredible amounts of trust in the system and the people operating within it. When plans and contracts turn into forecasts, accountability becomes elusive. How can you hold somebody accountable for an output that’s designed to change as we go along?

This is why seldom, if ever, you see agencies truly get to do agile beyond the “we do sprint planning and standups and stuff” pageantry. Customers that trust an agency enough to truly have them operate in the manner that embraces agility are as rare as a sober Finnish person. Every time budgets are committed, the corner office wants to see in advance what the outcome of the investment will be.

Even with in-house development things can get tough. Financial plans need to be made and marketing and sales need dates to build towards. Being agile can’t mean running a kindergarten.

That’s where a truly agile-minded Product Manager can truly bring a ton of value. With the right tooling, organization and process in place you can be 100% true to embracing core values of agile, while still giving a constant output of a roadmap. One that isn’t a contract, but a forecast based on the best information available at this moment. Acknowledging that 5 minutes later, we may already have much better knowledge available.

Six Telltale Signs of an Agile-hostile Environment

As a little added bonus, here’s a few ways you can identify if you’re just faking the funk. If you find yourself identifying your organization with one or more of these characteristics and you’ve been struggling to make Agile work in your organization, you can breathe a sigh of relief — It’s not your fault!

1. Roadmaps are considered a contract not a forecast

Don’t get me wrong; roadmaps, forecasts, dates and other scary things are really important. Any serious business needs them to operate properly and have an understanding of where they are going.

There’s nothing anti-Agile about looking into the future. Things start getting wonky when predictions into the future become contracts.

If your environment doesn’t support the concept of roadmaps evolving as we learn more about our priorities, really doing Agile won’t be possible.

Here’s how to shift to data-based forecasts from made-up dates you have to back into:The Baller Way to Forecast Delivery Dates
Managing dates can be a P.I.T.A. — but if you keep it lit with Scrum, you can see the future with 20/20 clarity.medium.com

2. Your Agile process is wrapped in a fixed-scope / fixed-budget contract

This is true for a huge portion of all agency work. Even if your team runs the basic Agile rudiments, but somewhere up the value stream there’s a contract that defines a fixed outcome and fixed amount of budget, you’re basically just fooling yourself.

3. Competency-specific teams

If you hear terms like “tech teams” when it comes to the machinery that builds products, alarm bells should go off. To truly embrace Agile, feature teams should be aggressively autonomous and cross-disciplinary. If the team you’re managing has to consistently rely on outside input to deliver value, something is off. Agile is often mistaken to be a tech methodology when in fact, it’s a product delivery methodology and should cut across all the competencies required to deliver products.

How to properly organize teams to support proper Agile is a topic of a full post later.

Solution: Squads & Guilds:Why the Ghostbusters are the Perfect Agile Team
Build your team to really embrace Agile with the help of the Ghostbusters and Spotify.medium.com

4. Dependencies upon dependencies upon dependencies

Handoffs are evil. If the way your organization handles product delivery resembles a spider web of dependencies, I guarantee you nothing even remotely resembling Agile will happen. Autonomy is key to Agile value creation.

5. Culture of priority drive-bys

Owning a backlog is only possible if you can guarantee with 100% certainty that nobody else has access to change priorities or add things in. If your organization allows for anyone to mess with someone’s backlog willy-nilly, change will go unmanaged.

This should be true for everyone up & down the chain of command. Any changes in priority should still go through the Product Manager, even coming from the very top.

Natural disasters, critical bugs and other force majeures excluded. And Executive swoop-ins.

6. Constantly changing teams

Agile relies heavily on the ability to forecast the output of a team. Teams that constantly change won’t have time to gel together, nor do they produce a predictable output.

Value stream that doesn’t embrace the inevitability of change.

If any of these criteria rings true, you might want to consider addressing those first. Quite often when I run into teams that have tried Scrum or Kanban and decided they just don’t work, I find that there’s at least a few of these lurking in the background.

I realize most of these are beyond the possibilities of a Product Manager to fix, but advocating for sanity should always be in our bag of tricks anyways.

Keep trucking and remember that no matter what you do, you can’t avoid the certainty of change.

On the flipside, to create an environment where Agile truly gets to shine, here’s 5 tips for a great start.