6 things I wish I knew before we moved from Waterfall to Agile

When you’re a small business it’s pretty simple to decide what you need next. As a high-growth start-up, we at Naked Wines could easily get everyone in a room and decide what the tech team needed to build in order to make us more successful. Fast forward 12 years, add US and Australian business units, triple the size of the team and things are a little more complicated!

We knew we needed to do things differently to continue to succeed. We decided Agile Product Management would give us the flexibility we needed to keep growing as a company.?

Two years into our transition we’re reaping the benefits, but we’re also still evolving; figuring out ways to make our products even better.? In this article, I’m going to share my top tips for how to make a smooth transition from Waterfall to Agile so if you’re looking to make the switch you can make the best possible start.

1. How to “sell” Agile

One of the most important parts of transitioning a business from Waterfall to Agile is convincing stakeholders it’s worth the trouble. If you’re planning any big change to your organisation the first thing you’ll need to do is get the support of some influential people. Generally this means pitching to the leadership team.?

When pitching, it’s really tempting to focus on things that appeal to your stakeholders in their current way of working. Often the biggest criticisms of Waterfall are that it’s slow and difficult to adapt when something changes. So your pitch could go something like:?

“You’ll get what you want faster and we’ll be able to change direction quicker”

Sounds tempting right? What’s not to like? BUT if you want your Product function to really fly, you need long-term collaborative buy-in. It needs to last long enough for you to survive the inevitable bumps that come with a big change like this.?

Let’s take the pitch apart and start with “You’ll get what you want faster”. This is only true if “what you want” is precisely aligned with the top priority of one of your Product squads. There’s big work to do early doors to close the gap between ‘what Product thinks it should be doing’ and ‘what stakeholders think Product should be doing’.?

What about “we’ll be able to change direction quicker”. The word ‘Agile’ has some powerful connotations in the business world. It just FEELS aspirational, especially in bigger organisations where all you want day to day is the ability to move quickly after opportunities that just make sense, without the feeling of trying to steer an ocean liner.?

However, you need to get good early on at explaining the difference between good agility and bad agility.?

Good agility looks like - the discovery on project X isn’t as promising as we thought it would be, let’s shelve it and look for something else to do.?

Bad agility looks like - stop what you’re doing and look at this.?

You need to help your stakeholders understand where you are in the lifecycle with particular projects and the relative cost associated with change.?

Some common phrases you might hear back include:?

• “We as decision makers want to be very involved, let’s have a weekly prioritisation session”
• “You told me that discovered project X and undiscovered project Y are roughly the same size, I want to do Y now and X later.”?

If you’re hearing this then work a bit more on creating trust in the Product function as a whole. You need to speak more about the rigour you’re applying to the decision to build X not Y and communicate that to your stakeholders.? Speaking of communication…

2. Communicating a vision is easier than talking about smaller stuff.?

When you’re transitioning, the most important thing you need to do is sell the clarity you get through a really strong Product function. The feeling of being able to relax as a stakeholder because there’s a whole team working on what the next right thing looks like.

A healthy Product function is the data-led aggregation of all ideas in the business into one single voice.

How you communicate that back to stakeholders is critical. If you want your stakeholders to relax they need to understand the plan but that shouldn't mean they understand the granular detail - the effort required from them would be far too great.?

For example, It is not important to tell your CEO that you’ve fixed 12 bugs this week including a minor issue affecting customers adding addresses to their account in Utah. It is important that your CEO knows that your squad’s vision this year is to “make account management feel effortless”. So long as they know that, they know what you’re doing and can explain it to others without having to sweat the small stuff (that’s your job!).

3. You need to build trust as quickly as you can.?

If everyone agrees with absolute clarity what the next right thing is, I don’t believe there’s a faster way to get things built than Agile Product Management. BUT if your stakeholders aren’t bought into the product vision then practically all they’re experiencing is the same as before; you’re not doing their thing and there’s very little they can do about it. Think about the other departments in your business - do you know how the accounting team functions day to day? Likely not, but, you trust that their outcomes will be what you need.?

4. You have to find the fun to unlock resilience

You and your team need to find a way to cope with setbacks. You are going to make mistakes, processes are going to change and then change again, creating waste which can feel pretty frustrating.? You need to find a way to cope in a healthy and positive way. My team’s key coping strategy is memes. They help create a psychologically safe environment to have a whinge about something that’s gone wrong and then move on but you can pick anything that works. Make time for retros which discuss setbacks and talk about how to do better next time.?

5. The best teams make space for people to do what they’re best at

When you move to a new system it’s really tempting to cling to a comforting process doc that you wrote at the beginning of the transition to keep you on track. The best thing we did as a team after the first 6 months was to let go of what we “should” be doing and start doing what we felt made sense.?

Letting go of clearly defined roles and responsibilities and working as a team towards a common goal yielded much better results (though it’s a bit of a balancing act reconciling the benefits of a unified process with the flexibility to let people do what they do best).?

This also means giving the experts in your team room to shine by acknowledging that the Product team is not a democracy. For us this looks like: when a Designer presents wireframes we discuss how to serve them from a back-end perspective, what the MVP might look like, how we might go about testing them but NOT whether green is the right colour for the “Buy Now” button. That’s a design choice and we trust our Designer to do the right thing.?

6. You have to be realistic - Always underpromise and overdeliver

This is possibly the most important thing to bear in mind. Switching from Waterfall to Agile is a pretty painful process. It’s very tempting to promise upfront that you’ll be up and running and faster than ever before in 6 weeks -you won’t. Be realistic above all else. Agree when you’ll check in about how it’s going with key stakeholders and share your success (however small to begin with!) in order to keep leadership on side and take the pressure off while your team finds their feet.?

Living the transition from Waterfall to Agile Product Management has been two of the most interesting years of my career to date. I’ve learned loads and although there have been tough times, I think it’s been more than worth it.

Are you going through something similar, is there something important that I missed? Let me know in the comments - I’d love to hear from you.?