Can agile methods actually scale?

Transcript

Matthias Orgler:
Now there's like that hype. Everyone wants to be agile because it's just hip to be agile.

Nicole Spence-Goon:
And if people aren't willing to make that commitment, then maybe they're not ready to scale at all.

Christine Dela Rosa:
Welcome to Work Check, an original podcast from Atlassian, makers of teamwork software like Jira, Confluence and Trello. I'm your host Christine Dela Rosa. On this show, we take workplace practices and separate the hype from the helpful. Each episode, two Atlassians debate how the practice should be applied. And today we're talking about agile.

Christine Dela Rosa:
The big question being: should agile practices scale company-wide? Let's meet our debaters: Arguing for scaling agile, we have Kelvin Yap!

Kelvin Yap:
Excited for this one, Christine.

Christine Dela Rosa:
And arguing against scaling agile, Dominique Ward.

Dominique Ward:
I've got strong opinions about this.

Kelvin Yap:
Bring it on.

Christine Dela Rosa:
Before we get into what promises to be a controversial debate, let's level set with a little agile 101.

Christine Dela Rosa:
agile is an approach to work that helps teams develop products and deliver them to customers quickly and smoothly. How? Rather than have one giant project launch, agile teams deliver continuously. That way they're able to collect customer feedback and use that to help them revise or change direction along the way. Today, it's a popular practice, especially in software development teams and project management. But surprise! It's actually a relatively new practice. In 2001, a group of 17 software developers gathered in Snowbird, Utah – not to ski the slopes, but to figure out how to speed up the development process. They were frustrated with the slow pace of the traditional "waterfall" method. Together, they put their recommendations down on paper, into what we now know as the agile Manifesto.

Christine Dela Rosa:
This Manifesto outlined a bunch of values and principles, like "individuals and interactions over processes and tools," "working software over comprehensive documentation" and "responding to change over following a plan."

Dominique Ward:
Okay, but let's not pretend that all agile companies are living and breathing that manifesto.

Christine Dela Rosa:
True. True in the years since, practitioners have turned these ideas into frameworks to deliver agile to companies and help them scale. Today, we're digging into agile at scale more broadly. But there are tons of specific approaches. There's Scrum, SAFe – which stands for a scaled agile framework, LeSS – large scale scrum – or even "The Spotify Model," which some would argue is not a framework at all.

Kelvin Yap:
Shots fired.

Dominique Ward:
Well, she's not wrong.

Christine Dela Rosa:
Thank you, Dominique.

Christine Dela Rosa:
So today we're looking at agile at scale. And when we say "scale," we mean both horizontally and vertically. "Horizontal" scaling means a company is bringing agile to all of their teams, and "vertical" means the company uses agile practices in how those teams work together.

Christine Dela Rosa:
And when we say "true," we mean all of the practices, ceremonies, and even the mindset. Nowadays, most people believe agile can work for teams, but some in this field don't see it as an effective strategy company-wide. Let's get started.

Christine Dela Rosa:
Debaters, as always you get three rounds to make your case. Now I want a good clean debate, no low blows, and keep it snappy. Dominique, Kelvin, today's question for debate: Should true agile adoption exist at scale?

Christine Dela Rosa:
Dominique, kick us off for round one. Why should it not scale?

Dominique Ward:
Thanks Christine. I'm a data nerd.

Christine Dela Rosa:
Check.

Dominique Ward:
So I wanted to start us off with some research to ground our conversation. I know how I feel about scaling agile, but what does the data tell us? How are companies who try to adopt scaled agile doing? As I suspected, not well at all.

Dominique Ward:
To share her research, I want to bring in Dr. Heidi Gardner. She's a distinguished fellow at Harvard Law.

Kelvin Yap:
Ooh, bringing out the heavyweights already.

Dominique Ward:
Right?

Dominique Ward:
So Dr. Gardner and her colleagues study agile transformation. And their research looked into 112 companies that attempted to scale agile.

Dr. Heidi Gardner:
And what we were trying to understand is why across all of these organizations who had attempted agile transformations, a few of them perhaps were resounding successes, and so many other ones had essentially fizzled out. There was a pretty high failure rate. A very high proportion didn't reach the objectives that they had set for themselves.

Dominique Ward:
90% of companies in that study reported that they struggled or failed to transform – even after succeeding with smaller agile initiatives. In some cases, these companies were trying to apply agile methodology straight out of the box that simply didn't fit them. Others were asking high performers at their companies to lead agile initiatives, which of course ended up burning them out. In all of these cases, they struggled to transform.

Kelvin Yap:
Okay. 90 is a big number. But just because something might fail doesn't mean we shouldn't try. If we had that attitude, then mankind would never have made it to the moon, or Australia would never have gifted the rest of the world Vegemite.

Dominique Ward:
Listen, take that moonshot. But for so many of the organizations that try and fail to scale, it actually causes massive ripple effects throughout their companies. In fact, my other guest Matthias Orgler, a software engineer and agile coach with a decade in the field, had a great analogy for this.

Matthias Orgler:
It's kind of like having an old house and you want to remodel it. Maybe you have to tear down a few walls, but if you then stop in the middle of that tearing down, you have a worse situation than your starting situation. So if you're not prepared to follow through, my recommendation would be, don't do it.

Dominique Ward:
And there are so many consequences companies can face when they don't pull off the full remodeling.

Christine Dela Rosa:
Yeah.

Dominique Ward:
Dr. Gardner and her colleagues found that failing to scale can slow down product development, which is ironic given that agile was created to speed up development.

Christine Dela Rosa:
Twist!

Dr. Heidi Gardner:
Sometimes it means that a very important initiative simply loses steam or never actually fully gets off the ground.

Dominique Ward:
And they also found that it can lead to burnout in staff or create conflict between teams. Matthias said a big issue he's been seeing is losing talent.

Dominique Ward:
During the attempt to adopt scaled agile, workers are promised all this agency and freedom. So when it fails, it can lead to bitterness.

Matthias Orgler:
Those people will become frustrated. What usually happens is they will leave. They will leave the company and you will lose your best people. And that's the danger of half-assed agile transformation.

Dominique Ward:
Neither of my guests are saying agile can't scale. But if 90% of companies are struggling to transform, that means that in 90% of the cases, companies could lose talent, slow down development or create conflict. That just doesn't sound worthwhile to me.

Christine Dela Rosa:
Dominique, strong point and strong evidence. It's worth considering those side effects of failed scaling carefully. Kelvin, what do you have to say about that?

Kelvin Yap:
Well, I actually think Dominique and I are in perfect agreement.

Christine Dela Rosa:
Second twist of the debate. I love it.

Kelvin Yap:
I agree that you can't go halfway with an agile transformation, but I see that as an argument in favor of scaling.

Dominique Ward:
You would.

Christine Dela Rosa:
Hey, I'm intrigued. Go on Kelvin.

Kelvin Yap:
Listen, 90% is a high failure rate, but these types of transformations are hard. And a lot of companies are choosing to scale agile for the wrong reasons or approaching it in the wrong way.

Kelvin Yap:
My first guest, Nicole Spence-Goon, is a certified agile coach at Excella and has led agile transformations on some massive projects. And she's definitely seen the issues with companies going only halfway towards adopting agile.

Nicole Spence-Goon:
If you have some teams that have gone agile and then some that have not, you're going to encounter some bottlenecks, because the teams that are agile, they've worked out their processes within their piece of the pie. They're chugging along and chugging along and chugging along. And then they come to the handoff, it's kind of coming up against a brick wall. It's like, okay, well this is going to slow us down. We'll be able to crack through the wall, but it's going to take a little bit longer.

Kelvin Yap:
It's going to be extremely frustrating for both the agile and non-agile teams if their workflows don't line up.

Christine Dela Rosa:
Right. Right. It's kind of like making sure everyone on your team uses the same tools or common language. It creates consistency.

Kelvin Yap:
Exactly. So by scaling agile across all the teams, you can actually solve some of the issues Dominique laid out. And look, I'm not trying to tell anyone that scaling anything, let alone agile is easy. The logical solution here though, is doubling down in the commitment to scaling and reaping the benefits, not to stop trying.

Christine Dela Rosa:
Investing on improvement. I like it Kelvin. Clearly though, I agree with both of you. Scaling means scaling all the way. But I got to say, 90% of companies struggling to scale is really high. So unless Kelvin, you can prove that struggling to scale is still going to help more than hurt, I'm going to go with Dominique on this one.

Dominique Ward:
Wonderful.

Christine Dela Rosa:
Dominique, keep us rolling into round two.

Dominique Ward:
All right. So scaling means bringing this methodology to all teams, right?

Christine Dela Rosa:
Right.

Dominique Ward:
I don't believe that agile, true agile, suits all teams. By scaling agile, you're forcing all teams to operate in the same way, which makes no sense if the goals and needs of the team aren't the same.

Dominique Ward:
I've spent nearly 15 years working with design teams across several industries. And agile has not worked for many of those teams. Design is all about problem solving. And often at the start of projects, our goals and solutions are undefined, and outcomes hard to predict. agile forces us to jump to solutions quickly, at times rushing through parts of the design process, lest we be told that we're slowing down the team's ability to ship. agile was created by and for developers to solve the pain points of software development process – most notably, speed. But some teams have very different needs than engineers. 17 developers in a room does not an inclusive cross-functional way of working make.

Kelvin Yap:
That's fair.

Dominique Ward:
So of course the skills, research and time needed to design user experiences were not considered. And the ripple effects of that lack of consideration play out on teams, and ultimately on the user experience.

Christine Dela Rosa:
Fair.

Dominique Ward:
To deliver on that speed, designers have to be laser-focused on a feature or aspect of an experience. And it's often completely removed from the larger context of that broader user experience. And then it's just onto the next.

Christine Dela Rosa:
Dominique, in the spirit of sharing, I'll come clean.

Dominique Ward:
Please do.

Christine Dela Rosa:
Well, you know I'm on the brand team. And we also don't operate in a true agile way. We work on longer term projects, so it doesn't make sense for us to chunk our work into two-week sprints. If we did that, we wouldn't be able to utilize partnerships or develop content that can take months to research, test and then put out there.

Dominique Ward:
Thank you. It's the same for us. I've also noticed that when everyone is agile, there's almost no time to take a step back to envision the future or set a North Star of the user experience we're working toward. Nor is there always someone who has a view of what all of those pieces will look like when they come together.

Dominique Ward:
What emerges is “le cadavre exquis” (forgive my terrible French) – the exquisite corpse. You know that parlor game?

Kelvin Yap:
Of course.

Christine Dela Rosa:
Yeah. But I mean, for those that don't know, what is it?

Dominique Ward:
Well, everyone draws a different part of a person, and then they put all their drawings together and what emerges is this magnificent Frankenstein. Which is great for a party fodder, but terrible for product experience.

Christine Dela Rosa:
Uh-huh (affirmative). I see that.

Dominique Ward:
Scaling is forcing a round peg into a square hole. Absolutely. We can go through the motions of agile if that's what we need to do to get along, but why?

Christine Dela Rosa:
Totally. And I relate to this point, really. I'll just say that I work with a lot of teams who do practice true agile. And to be in step with them, I take part in sprint planning, show up for iteration reviews, and join retros at the end of projects. Can it feel rigid having to snap into another team's way of working? Sure. But I've gotten used to it because I know it helps those other teams. And so Dominique, I've embraced working with agile teams, but also have accepted that it's not a perfect fit for us.

Kelvin Yap:
One follow-up question, Christine. You mentioned it helps other teams for you to work this way. How so?

Christine Dela Rosa:
It gives me an appreciation for their workload, like what they have to go through.

Kelvin Yap:
So you're saying that norming to one way of working helped bridge a connection between different teams and build empathy?

Dominique Ward:
Leading question.

Kelvin Yap:
Actually don't answer that because this leads me to my next point.

Christine Dela Rosa:
Great. Close out the round for us, Kelvin.

Kelvin Yap:
See, I totally disagree with your argument Dominique, that your team can't be agile. And don't dock me points, Christine, but your argument too.

Christine Dela Rosa:
Is that so? I'm on the edge of my seat.

Kelvin Yap:
I hear this criticism all the time – that some teams can't work in an agile way. And I really think it's misleading.

Kelvin Yap:
When I chat to our customers about their processes or even how my product marketing team works at Atlassian, the problem lies less with agile and more with struggling to adapt your approach to how you get work done. I want to introduce Ben Bard, the engineering director at Lutron Electronics, a company that makes smart dimmers and lighting controls. And they recently underwent a scaled agile transformation themselves. They did it because they realized that having their software team doing agile, and their hardware team working differently, simply wasn't working.

Ben Bard:
We had teams in probably seven or eight locations all over the world, trying to collaborate with each other. And we were under a tight timeline with the biggest project in our company's history. We were having all kinds of challenges and we couldn't stay aligned across those locations on something that complex. And so that's what led us to need something new because our process was breaking. And so it was really the tension between software and hardware that led us to go there because we needed to work together.

Kelvin Yap:
But it wasn't easy getting the hardware teams on board. One of the biggest challenges being – like you said Christine – how do you divide work into chunks that also make sense?

Christine Dela Rosa:
Right.

Kelvin Yap:
The hardware team needs to order from vendors, get materials and molds. And waiting on a shipment does not divide neatly into two week sprints.

Christine Dela Rosa:
Exactly.

Kelvin Yap:
But they eventually found a solution that has served them well.

Ben Bard:
So rather than delivering something shippable, they looked at a learning cycle or a what's the thing we could learn. So if you're going to make a prototype and be able to learn something that will help you with the design – that you can do in two weeks.

Kelvin Yap:
I love this flip from deliverables to learnings. And Dominique, Christine, I genuinely think this adaptability could help both of your teams too. All work can be broken into chunks if you look at it differently. This debate aside, hopefully, I can convince you both to come on board and try again.

Christine Dela Rosa:
I'm listening.

Dominique Ward:
Don't bother.

Kelvin Yap:
We can learn a lot from what worked at Lutron. Sure, they had 30% more year over year output. And sure, it was great for their bottom line. And sure, it's been crucial for staying competitive in their field. But even more importantly, it's been huge for alignment. Having everyone in all those locations on these different teams working the same way, meant that they could move forward together on those big goals.

Christine Dela Rosa:
That's well-put. And with that, round two is over! I can't really disagree with either of your points.

Dominique Ward:
But you will.

Christine Dela Rosa:
Well, Dominique, your critique spoke to my real life experiences, right? And Kelvin, your reframe about learning as a sprint goal sounds pretty ideal – if it's actually attainable.

Kelvin Yap:
It is.

Christine Dela Rosa:
With that attitude, this round goes to Kelvin!

Dominique Ward:
Of course.

Christine Dela Rosa:
Kelvin, why don't you start round three off with your final argument.

Kelvin Yap:
Oo, I get to go again. Okay. I'll keep convincing you both to join me on the light side. So on top of the alignment point, scaling agile is incredibly beneficial for empowering teams so they need less leadership oversight. Ben Bard saw this play out in Lutron's company chat recently when two leaders in the hardware team were on vacation.

Ben Bard:
And somebody asked the question, well, how's it going to continue to run? And one of the kind of key skeptics said, it runs itself. And just posted a GIF of a train chugging along. So basically saying the release train keeps the work flowing. Those key people can now focus on changing and direction and vision and much higher level things, which I think make us much better than needing to be there to keep it going, so to speak.

Kelvin Yap:
I feel like this really shows how scaled true agile is good for everyone. Both the employees who have the power to keep that release train going, even when their bosses are away, and it's good for the leaders who can spend their time actually leading. I mentioned before that my other guest, Nicole Spence-Goon, has run some pretty large scale transformations. Well, I mean seriously large. She supported the US Citizenship and Immigration Services as they scaled agile, and found the teams that benefited from this sense of empowerment.

Nicole Spence-Goon:
They gain more ownership, some more skin in the game because they have some more autonomy. So it's like, I'm the master of my destiny here, because now I can make the decisions about how I'm going to approach this work.

Kelvin Yap:
When I think of an organization that large, I don't necessarily think of words like agency or autonomy.

Christine Dela Rosa:
Me neither.

Kelvin Yap:
But it turns out agile can empower all teams, even if you do work for a federal agency. And when teams are empowered, they have more ownership, care more about quality and end up being more productive. Nicole advocates for customizing your agile transformation, not just straight out of the box applying an agile framework. She even encourages teams to iterate on the agile process itself as you're finding what works for you.

Christine Dela Rosa:
Meta.

Kelvin Yap:
While I do recommend adopting and familiarizing yourself with core agile processes before customizing the way you work, at the end of the day agile is a set of values and principles.

Christine Dela Rosa:
Oh right, right.

Kelvin Yap:
We can get caught up with criticizing elements of the Manifesto or certain frameworks and processes. But remember, the first value of the agile Manifesto is "individual and interactions over processes and tools." It's about people over process. And if scaling agile can bring the people in your company alignment and empowerment, then I say scale away.

Christine Dela Rosa:
Nice Kelvin. People over processes is key. Way to bring it back to the Manifesto. All right, Dominique, what's your final say?

Dominique Ward:
So my last point is probably my most controversial. So strap in.

Christine Dela Rosa:
Ooh.

Kelvin Yap:
Here we go.

Dominique Ward:
Christine, you started by telling us the origin story of agile way back in 2001.

Christine Dela Rosa:
Yep.

Dominique Ward:
To put it another way, the agile Manifesto is older than the original iPod. The problems it was solving, especially in software, are very different from the problems today. Some agile thinkers say that agile is dead. I don't know about that, but I'm more curious if true scaled agile really exists.

Kelvin Yap:
Scandalous.

Christine Dela Rosa:
Operative word being true?

Dominique Ward:
Yes. But let's keep it a hundred. agile is so hot right now. My guest, Matthias Orgler said this is motivating a lot of companies to jump on the agile bandwagon without a lot of consideration.

Matthias Orgler:
All our competitors are becoming agile, that's why we want to become agile. Or we need that marketing stem, "agile company," because then we would be more attractive in the labor market to software engineers because we're fighting for talent there.

Dominique Ward:
And in a lot of these cases, I'm not sure how true their scalings really are.

Matthias Orgler:
It's like they painted their old Geo Metro red, and now they think they're done making it a race car. Most companies actually think that they are agile, and most of them only do frameworks and processes and roles.

Dominique Ward:
And they're not doing the deeper transformation that would make them "true" agile. Remember Dr. Gardner's study and the 90% that struggled to scale? My guess is that if we looked at the 10% that are succeeding, we'd find some fake agile...or dare I say "fragile" behaviors.

Kelvin Yap:
Uh-oh.

Christine Dela Rosa:
Fake agile meaning they're doing these surface level aspects of agile without the mindset or cultural shifts, right?

Dominique Ward:
Exactly. And that's because agile is a promise. Kelvin, you've done a top-notch job today selling that promise.

Kelvin Yap:
I have.

Dominique Ward:
Of inspiring us all to live that promise. But when you look a bit deeper behind the shiny promise of scaled agile transformation, there's not a lot of evidence of success. A coach named Geoff Watts referred to true agile scaling as the holy grail.

Dominique Ward:
He says, we've been chasing it for 20 years now and thinks that it might not fully exist at any company. Again, I don't know about that, but I do know that a lot of what is considered agile adoption involves a lot of picking and choosing bits of agile to adopt. When companies set off on their quest for the holy grail, they end up spending a crap ton of time and money trying to force their organization to scale agile. And as we've heard, many of them are failing. And in the process disrupting their teams, Dr. Gardner cautioned that leaders go into this process with clear expectations.

Dr. Heidi Gardner:
Organizations have to be realistic about what this methodology can achieve. It's not a panacea.

Dominique Ward:
That's right. It's not a panacea and it's no cure all. The issues that make most organizations want to adopt scaled agile are complex and require deeper work. So if scaled agile ever existed, or ever worked, we can see that it's not working now. And there's something to be said about recognizing when to pivot. Spotify, for example, doesn't even use the Spotify model anymore.

Christine Dela Rosa:
Oh yeah.

Dominique Ward:
In the spirit of transformation, maybe just maybe, 20 years after the invention of agile, it's time to look for an alternative.

Christine Dela Rosa:
Wow. Spicy. Good work to both of you! Dominique, you make a good point. We should think critically whenever anything is sold as a blanket solution. And every company should beware "fake agile." That said, agile scaled well has huge benefits for team empowerment, as you said, Kelvin. I bet that in the early years of agile, we would have seen an even lower success rate than scaling initiatives today. So call me an optimist because I think as more companies get better at scaling agile, the success rate will go up and we can keep pushing for better ways of working. Which means, the winner of this round and today's debate...is Kelvin!

Dominique Ward:
What?

Kelvin Yap:
Never in doubt. Look Christine, like any good sprint, this victory was estimated and executed to perfection.

Dominique Ward:
This is rigged. I demand a retro.

Christine Dela Rosa:
So scaling agile, as we saw today, is challenging, but it can have real benefits for companies that are able to adopt it fully. Here are a few considerations.

Christine Dela Rosa:
If you're going to do it, think hard about why you're doing it and if you are the right fit. If you're a company used to a command and control leadership style, scaling agile might be a bumpy ride. And if you're going to adopt agile at scale, you need everyone on board. Empower your teams and let them iterate on the agile workflow in a way that fits them. And finally, when in doubt, rather than getting caught up in the terminology and the frameworks and ceremonies, go back to the manifesto. The original principles still hold and they can scale.

Dominique Ward:
True.

Christine Dela Rosa:
That's it for our episode on agile. Thank you to our debaters Kelvin and Dominique.

Kelvin Yap:
Thanks for having me.

Dominique Ward:
Always a pleasure.