Scaling Agile beyond IT

Peter and Dave discuss the difficulty of taking Agile practices out of IT and into the rest of the organization. We discuss the need for creating a common language and acknowledging the differences between areas. There may even be some hints about how to overcome these adoption barriers.

We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com

Transcript

Peter [0:06]: Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Welcome Dave, how are you today?

Dave [0:16]: Doing well, doing well! Actually, I was just thinking I'm getting a little cold here in my office, but I feel like I'm being whiny when I'm in Vancouver and the rest of... well, the whole North American continent is in a deep freeze right now.

Peter [0:32]: laughs Yeah, we've been under quite a bit of snow on this part of the country the last couple of days. We've got about a foot of snow now, I think.

Dave [0:40]: Well, we had snow for the obligatory three days, and now it's gone again. Back to normal Vancouver weather.

chuckles You realize how English we're being right now, just talking about the weather...

Peter [1:02]: laughs Well, this is how we find our groove when we're having a conversation, right? There you go, exactly!

So today, we were chatting about maybe diving into something that's come up for me a couple of times this week - this concept of scaling Agile beyond the IT department. It's such an interesting topic, and I've seen it approached in various ways. But one comment that really stuck with me was from someone who said they've seen it fail every single time. Every time it tries to grow beyond IT, it just hits a wall and dies.

What's your experience been like with this?

Dave [1:30]: I'd say pretty much the same, but I think it's all contextual, right? Depends on the situation and what's already there.

One thing I think we forget is how Agile first launched itself and became a big part of software development - it was solving a very specific problem. But there's this aura now of "oh, Agile will solve all these problems" without any consideration of what the actual problems are that need solving, and therefore how we should go about solving them.

Peter [2:07]: Yeah, totally agree! I was talking about this with someone yesterday - it was actually a purely technical question, but it illustrates the point perfectly. He was saying, "I'm fighting with one of my technical guys because he can't seem to get logs to write locally into this container." And I said, "Well, have you stepped back and asked why he's trying to do that? Because that's a bit of an odd thing to do."

Dave [2:39]: laughs That question - "why are you trying to do that?" - is exactly where you need to start, right?

If I come in and say, "Agile worked really well over there, so now we're going to do it here. This is called a stand-up, and I'd like you to stand up and talk about this and that..." - if we start trying to cookie-cutter what worked somewhere else, we've completely missed the point.

The real question is: why are you trying to change? Maybe you don't need to change! Or maybe you do, but what isn't working for you right now? That's where we need to start - both in technology and outside of technology.

Peter [3:14]: Exactly! We see people jumping on the bandwagon way too often. "Sign me up, I'm going to do Agile! Let's make the whole organization Agile because every problem needs to be solved this way."

But... does it? I mean, somehow you managed to grow a large business with lots of revenue, delivering value to customers. So what's the actual problem you're trying to solve? Why do you want to disrupt things by going through a change like this?

I don't want to sound totally anti-Agile - that's not the point at all. But we need to understand the "why" first.

Dave [4:02]: Well, the caveat is we probably believe you should do Agile in way more circumstances than most people do, just because of our backgrounds! laughs

But there's another piece here. There's curiosity, and there's a lot to be said for curiously trying new things. We can't treat every change like this big "why do we need to do it?" followed by some massive planning session.

What I find much more interesting are those organizations, those teams, parts of companies that actually function really well already. They just have natural curiosity to try something new, see if it works better, or if they like it more. In that case, we don't need the big "why" - they just need the safety to experiment.

Dave [4:57]: And that's a different problem. You don't go "all out Agile with a capital A." It's more about what principles and practices can be pulled in. Maybe it's as simple as making work visible, or learning some really basic touchpoints and the principles behind them.

You'll notice I'm not using any Agile terminology here, because I think that's another mistake people make. They come in with all this terminology that's well understood in the tech world but has zero awareness outside that space.

Peter [5:52]: Exactly! This happens in every area, not just technology. There's a part of a talk I do at conferences where I put up the Rosetta Stone - you know, the translation from hieroglyphs to ancient Greek that allowed them to decode hieroglyphs. It's in the British Museum.

But that translation challenge exists everywhere because different groups are all speaking different languages, using different tools, different acronyms, different ways of communicating. Bringing people to the table and giving them a common way of understanding each other is absolutely critical.

Dave [6:32]: And I've actually had a lot of fun - and seen really good success - in some very unusual settings. Whether it's schools working with students, or professional development days with teachers figuring out how to prepare for classes, or in one case I'm thinking of, preparing for a move from one school building to another during renovations.

When you're working in those contexts, the language you use has to be their language. They don't need new terms - they've got enough going on! But there's still value in that curiosity and some simple approaches that suddenly give them something new to play with. We're all attracted to shiny objects to some extent, but then there's also something applied and immediately powerful that they can pick up and use.

Peter [7:45]: Yes, exactly! And that language piece is key because we often... sighs ...as technologists - and I definitely count myself in that bracket half the time - there's this tendency to put people into buckets and pigeonhole them.

I was talking to someone about this the other day: am I a business person with some technology skills, or a technology person with some business skills? Depending on which bucket you're in, that's how you show up to conversations. We often don't even realize that when we're talking to technologists, we naturally use technical language, and we're completely unaware of it because it's just how we communicate with people around us.

Can you think of other examples where you've seen that kind of thing?

Dave [8:44]: Actually, this is quite peculiar timing - I just came from a mentoring conversation with someone who works in an innovation field in telecommunications. It's technical, but it's not about Agile language specifically.

Some of the challenges they're dealing with... you can hear there's a resonance around Agile principles. I think this is what Lean and Agile give us - that mindset provides a really interesting toolkit for looking at problems.

Dave [9:21]: I'm trying to be careful here - I don't think it means you can necessarily solve the problems, but it's a lens for looking at problems and understanding them from a systems perspective, from a people perspective if you think about how Agile teams work together.

That lens is applicable way beyond the technology world or manufacturing where Lean emerged. In this particular conversation, listening and applying that lens lets us ask different questions and highlight different things than we might with a different approach. I don't know if that's the example you were thinking of, but it struck me from today's conversations.

Peter [10:13]: That's a great example! And it makes me think back to the conversation that started all this, where someone was saying Agile fails when you try to move it outside of IT.

I wonder how much of that failure comes from the "bring everyone into a room and make a global decision" approach. You know, "we're going to inflict this on the organization, and thou shalt do it this way." You tell that marketing team over there - who've been working perfectly happily, understand exactly how to do everything they need to do, and are very successful - "Now you need to work in short iterations, write user stories, estimate this way, stand up at a board every day, or you won't get the organization's stamp of approval."

Peter [10:24]: Versus saying, "Hey, we want to help you solve problems better. What kind of problems do you have? What would be useful here?" Then inviting them on the journey to see if this might help overcome some of those problems.

Dave [11:15]: laughs Yes! I'm struck by another piece as you describe that. So many times, it's like we pack up our Agile toolkit from over here, walk over to a new department, and unpack the exact same toolkit. "You'll have user stories, you'll have a definition of done, you better have a standup every day..."

If I'm in the finance department, why do I need to stand up every day? Maybe I don't! Maybe I do, but there are lots of details around different, non-technical environments where we want to apply the principles but we don't necessarily want to apply the practices.

How do we avoid that "I know how it works here" cookie-cutter approach?

Peter [12:10]: Yeah, exactly! That cookie-cutter approach, or as I've heard it described, "dogmatic Agile." Where you're not allowed to do anything unless we come along and bless you with holy water and sprinkle some salt to make sure you're whole and okay to proceed.

Versus trying to help people understand and work within their context, in their language, in their space, to take these principles and use them to get better at what they're already doing.

Dave [12:57]: It's interesting that phrase - "dogmatic application" - because that doesn't work in technology either! It's very rarely a case of dogmatic application of anything. If anybody's coached a kids' sports team, there's no such thing as dogmatic anything in that environment, right? Same is true everywhere else.

We need to understand the principles. There are some great practices that work really well together in a given domain, but if I go to a different domain, maybe it's going to be modified sets of practices that work in that space.

Peter [13:29]: Yeah! And I know we're drifting into that technical space, but there was an article I read a couple of weeks ago that I... well, I enjoyed it because the author did a very good job articulating the problems he'd seen going through multiple organizations.

His conclusion was that Scrum and Agile just don't work. And they don't work because every organization he'd been in - and there were multiple - had ended up with bad practices that hadn't allowed him to be successful. Given how those approaches had been implemented, I couldn't really disagree with him. He articulated his point of view very well.

Dave [14:31]: That's the tragedy of it, right? It's situational! These are skills - we expect people to come with their brains and apply their brains to figure things out. That's when you really get the benefits, when people are engaged in the process.

There are definitely some things that work really well, and we're not going to deviate from those without really good reason. But the goal is that everybody's engaged in solving problems. We're not waiting for instructions on what to do next.

And we're human beings - we really hate being told what to do! laughs Just look at cultural differences in something as simple as queuing up. As good Brits, we're very controlled when it comes to lining up for things, but there are lots of cultures that deal with that very differently.

Peter [15:34]: laughs Yeah! The Indian train station where it's basically a free-for-all, elbows at the ready, and you just have to survive to get to the window. Or at the other extreme, I've been in Japan where they don't even bother with railings - just a couple of lines painted on the ground. Everyone lines up behind everyone else, never any cutting. It's all disciplined, nobody even needs to be told. And everything in between!

Dave [16:04]: Absolutely! And the recognition there is that queuing is one thing, but everybody's going to apply it in a way that's relevant to their experience and where they're at. There are lots of different ways of addressing the same basic need.

Peter [16:18]: So if you were to sum this up in a few words, Dave, how would you put it?

Dave [16:22]: Yeah, I think first of all, understand the "why." Be careful not to just say "hey, this works really well, so you need to do it too." Understanding why, coupled with that curiosity piece - curiosity is a great reason to explore something, but generally get the why straight first.

Second, stop trying to carry the language over. We really need to use language that's relevant to the domain we're stepping into. They don't need to learn all the terms we learned from our original domain.

And third, avoid the cookie cutter. You don't need everything in your toolkit - just the right things at the right time.

Peter [17:07]: If I were to list my three, I think it would be: make sure you're meeting them where they are - very similar to your point.

Another part is inviting over inflicting. Not telling people how it should be done by getting everyone in a big room and saying "this is the way you shall do it and you shan't do it any other way." Instead, create opportunities for people to learn.

And the third is exactly what you said about language - not trying to bring your own terminologies and ways of talking about things. Take the time to understand where somebody is, how they're operating, how they think, and what problems they're actually looking at.

So with that, I think we've wrapped up our time for today. Thank you as always - it's always a fun conversation!

Dave [18:11]: Always a pleasure, Peter! Great to chat again. Looking forward to the next one.

Peter: Likewise! You've been listening to Definitely Maybe Agile, where your hosts Peter Maddison and David Sharrock focus on the art and science of digital, agile, and DevOps at scale.