In this episode, Peter Maddison and David Sharrock discuss when not to use Scrum, the popular agile framework for software development. They explore scenarios where Scrum may not be the best fit, such as when an organization is resistant to change, lacks collaborative work, or operates in a highly complex environment with many dependencies and high failure costs. The conversation highlights the importance of understanding the problem, organizational context, and underlying assumptions before adopting any framework.
This week's takeaways:
Assess the organization's readiness and openness to change before adopting Scrum, especially if past attempts have failed or if it is seen as a quick fix.
Scrum thrives in collaborative environments; if the work is highly individualistic, Scrum may not be suitable.
A cautious approach is required in complex and high-risk environments, potentially adapting Scrum or considering other frameworks.
Tune in to gain a nuanced understanding of how to navigate agile frameworks in complex environments and make informed decisions for your teams.
In this episode, Peter Maddison and David Sharrock discuss when not to use Scrum, the popular agile framework for software development. They explore scenarios where Scrum may not be the best fit, such as when an organization is resistant to change, lacks collaborative work, or operates in a highly complex environment with many dependencies and high failure costs. The conversation highlights the importance of understanding the problem, organizational context, and underlying assumptions before adopting any framework.
This week's takeaways:
Assess the organization's readiness and openness to change before adopting Scrum, especially if past attempts have failed or if it is seen as a quick fix.
Scrum thrives in collaborative environments; if the work is highly individualistic, Scrum may not be suitable.
A cautious approach is required in complex and high-risk environments, potentially adapting Scrum or considering other frameworks.
Tune in to gain a nuanced understanding of how to navigate agile frameworks in complex environments and make informed decisions for your teams.
Peter:
Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you today? Peter, I'm doing very well, thank you. How are you? I am doing well, on my feet, again stretching my legs. So what are we talking about today?
Dave:
Well, we hit the record on this one because I think we're finally finding a space where you and I have different opinions on different things. So the starting question that we wanted to kick things off with was when not to use Scrum?
Peter:
When not to use Scrum? Yes, and here I think some of this may come down to Scrum as the framework Like when does it hit barriers? When is it?
Dave:
yes, yeah, and this is where where it's an interesting conversation, because both of us work in agile. You know, transformations in a lot of things we do and we we, you know use lots of different frameworks and approaches depending on the problems that we're dealing with, but at the same time, I'm a certified scrum trainer, so I this very sort of clear and a lot of the conversations I'm having very directly. This is how scrum works and this is when you should use scrum so I love this question because one of the things is you don't need scrum for everything.
Dave:
Stop using it for any and every problem that you have so let's think a bit. What are the, what are the things to watch for?
Peter:
where you start scratching your head and thinking, maybe scrum isn't the right way to deal with this yeah, yeah, and I threw a few down on the whiteboard here, but the ones that always the first couple of the year that I had was where you're running into an organization that's been there, done that, tried this, and they're just sick and tired and yet another coach coming in telling us that we have to do things, the scrum, and that's going to solve all our problems. We've been there, we've done it, we're tired, we're sick of this, it's not working and I don't want to do this again. Then it's probably not a good idea at that point to come in and start telling people how to do things, and if they're particularly allergic to the word scrum in particular, probably not a good idea to use that word.
Dave:
I was just going to say I'm not sure it's ever a good idea to walk into an organization and start telling them how to do things, but I've seen people do that.
Peter:
I've seen people do that. It's like this is the solution to everything.
Dave:
One of the most disarming statements I have learned over many years of doing this to say is uh, you don't have to use x, whatever people think, I'm going to come in and use because it's much more interesting to start understanding what are the characteristics of the problem exactly how? The team come up with ideas, or or maybe you know what can you learn um from other other?
Dave:
uh examples of success in a similar context and go from there, I think in both coaching kind of consulting, but also in teaching Scrum over many, many years. One of the things that never gets talked about in the Scrum guide but I think is super critical for really, really successful Scrum and therefore a reason not to use Scrum is the work has to be collaborative. There's an understanding.
Dave:
Yes, we want a team that's got agency and they're self-organizing in some way, they can do stuff and work in their environment and so on. All of that's true, but one of the sort of I would almost think of it like a hidden secret or it's hidden in plain sight is we need to have collaboration a secret or is hidden in plain sight, is we need to have collaboration, a need for collaboration across the members of the team.
Dave:
So, if you look at those things, you need work that needs multiple people contributing, working together to get that out of the door. And in so many times I've seen examples where that collaboration is not necessary, for whatever reason, and they're trying to use scrum on what they're finding. Yeah, just, it doesn't gel in the same way at all, because there's no need for the conversations that scrum is built around yeah, it's when you, you like, you hold, stand up and everybody's sitting there and here's my update but nobody else cares.
Peter:
Like this is. It's like because it doesn't impact anything that they do and everybody's basically off doing different things and none of it comes together in the end. And yes, I agree, I think that actually ties into some of the things that I've been saying here too is that if you can't easily work out how to come together to deliver on this, then you've just got a group. It's not really a team, for one thing. It's really just a number of individuals who are collected together in a group, but they're not delivering towards a common goal, or, if they are, they're delivering independent pieces of it, so that are so independent that they don't need to work together to do it.
Dave:
Any other things that you'd jump in when not to use Scrum.
Peter:
Well outside of the organization just isn't in a position to adopt that as the common piece, and I think this ties into your collaborative part of it. But if the team has so many dependencies outside of the group and this, I think, was the part that you were talking about where, even if they're a collaborative team, they can't in of themselves deliver consistently within a time box period, which would mean that trying to do a consistent time box delivery of something of value has scrum encourages, would be is completely out of their control there because they they can't do that because they've got too many other dependent, other things that they're always going to have to wait on um to in order to be able to deliver yes, and this is this is where um and and forget the scrum piece, when what you're describing there to me sounds like an incredibly complex environment, lots of dependencies.
Dave:
You know you pull over here. You don't know what the impact is so number one lots of people with specific knowledge that we need to bring to the table. Systems that are interdependent, possibly third-party systems you have little or no control over and in those contexts, everything about complexity tells me you need to take small steps, make small changes, to slowly gain control over that.
Dave:
Put some constraints on the system and then take small steps to understand the system, gain control of the system, learn about the behavior of that system as a system, both a technology system but a people system and a network of dependent entities and everything else in that and I think one of the key things there is you do need to be able to iterate on that. You need to make small changes over small periods of time.
Peter:
Do you create?
Dave:
a small dedicated cross-functional scrum team to do that? Probably not. Like you said, there could be 40, 50 people involved in lots of different ways. Should you take small steps and put constraints on the system to navigate your way through that? Absolutely so, that's sort of when I think of that. I think there are two different things then.
Peter:
Yes, yeah, and and I guess this is where it's the is is scrum, everything in the scrum, and if you don't do any one part of it, it's not scrum anymore. It's like, yeah, back to your earlier point. It's like what's suitable here to solve the problem? What is the outcome we're looking for? How do we help you get to that outcome? I've got a toolbox here full of different ways we can approach problems and let's see what's the right thing to bring to the table to help you.
Dave:
Well, and if I just use as an example so one of the other things which is somewhat related to what we're discussing right now, just to use as an example, so one of the other things which is somewhat related to what we're discussing right now. But again, scrum is built around an assumption that I can get a small this is what we're talking about some sort of small change to the system, completed in a short period of time, an iteration, a couple of weeks, a few weeks, whatever it might be.
Dave:
But if you're working in technologies that just aren't you can't move that quickly in, that just aren't you can't move that quickly in. Or you're working in technologies where the cost of failure is outrageous. There are probably better. You certainly just don't want to go in there blithely and say we should just use Scrum and one thing that jumps to mind. I just came back from the Scrum gathering in New.
Dave:
Orleans great events, lots of people. There had some great conversations and I've always used the sort of the throwaway comment about nuclear power stations and agile and scrum and I bump into somebody who's been an agile practitioner for many years and over those many years has worked in a nuclear power station and a nuclear energy utility, and that one is a really interesting one.
Dave:
I know you can definitely use agile and scrum and all the rest of it. However, at the same time you're looking at that going, I want to have only the best people coming up with experience on both sides of this one, because, a the technology is pretty specific and unique and, b the cost of failure is pretty outrageous. So how do you get that? And and I you know how do you navigate that?
Peter:
yeah, and I well, I think some of that comes down to the one of the first things that the the teams I need to do is like how do I experiment in that environment? How do I to your point? How do I remove some of that complexity? How do I abstract it away so that I can just focus in on something that is within my influence or control, so that I can start to iterate? It's the because obviously you don't want people delivering to potentially destructive production changes to a nuclear power plant.
Dave:
Well, and I think it's so the two things that come to mind about that one number one is absolutely agile mindset and Scrum. We often talk about it being a great way of managing risk and whether it's Scrum or some of the other methodologies, but there's a lot you can take from agile. So what we're not saying there is saying if you work in in these industries which have very high cost of failure or technology that's slower to be able to change in, for example, you cannot use agile. That I totally don't agree with. I think there's a lot that you could probably learn from that and use, and there's tons of great sort of mindsets and approaches there, but I think it also is so many times we think Scrum is the answer, or at least those of us who work in the context and that's where we come from.
Dave:
We think and I think that's a really. It's not the right mindset. There are many, you know. We want to understand the problem and bring the right tools to that problem in the right frame. Scrum certainly has a lot of strength, but it's not the only one.
Peter:
I think this ties into the other point. There, too, around it's not the silver bullet that's going to solve the pain point. If you have a problem where everybody's running around in chaos, moving in different directions going, and nobody's coordinated or aligned to work on a particular problem, scrum isn't going to solve that problem for you. You've got, effectively, a strategy problem and you have to work out like how am I aligned to what direction we need to go in? Am I trying to do too many things all at once? Have I got 150 programs all happening simultaneously and you say Scrum's not going to solve that for you at all? That's a whole other problem that you need to look at.
Dave:
Yeah, yeah, and I think that one is when I was thinking of this. I'm just thinking of the transformations. I'm sure you've seen this as well, and now it's just being. That's it. You know, we have a problem with X, y and Z, whatever it is, and Scrum will solve it.
Peter:
It's like totally the wrong way around.
Dave:
It's like how do you solve it? There are many tools, many things to bring to the table, but just pinning everything on your preferred framework is not going to be the way forward.
Peter:
Right, exactly, and maybe on a future episode we can talk a little bit about the strategy to execution connection that always gets lost, which is often called well, we'll just do Scrum, because that's going to solve all the problems. It's like well, even if you somehow improve your delivery capability, that's good, because that means you can experiment more. But if you still don't know what direction you want to go in, then not very helpful.
Dave:
Faster in the wrong direction Exactly.
Peter:
So if we think of how we were going to sum this up in three points, what three points would you pull from this?
Dave:
Yeah, so let me try and pull one or two and see if you can add a couple in there as well. You started straight at the outset, which is the way I'm interpreting it Is the organization trying to adopt whatever the framework is from the right place.
Dave:
So is it burnt out and sick of yet another coach, or if we're trying to treat it as a silver bullet. All of those things are really not setting any transformation of the success. So I think the first piece is is your organization approaching this from the mindset of this is the right framework for the challenges that we are faced with and this is likely to move us in the right direction? Or are they sort of just, you know, pulling at straws and hoping that, by naming Scrum as the way forward, that somehow some of the other underlying challenges they have in the organization are going to disappear or stay hidden for a bit longer, then that's not going to succeed.
Peter:
Yeah, I'd agree.
Dave:
Then I think the second thing is there's a bunch of sort of assumptions and we always, whatever framework we're going to use, we want to look at the assumptions behind it. So there's an assumption of a collaborative work. So you've got collaboration on the team, some agency or autonomy on the team. If they don't have agency or autonomy, how on earth are they going to be able to explore it and innovate and change the way they're working right?
Peter:
And then thirdly, is that.
Dave:
Can I get product out of the door? Is it too big and scary and complex to actually be able to make a change and get it out within a short iteration? That's not possible. We're going to have to rethink the approach.
Peter:
That's three and three so there we go.
Peter:
Bonus. I think you covered off the silver bullet, another piece along with that, those parts of it, I think, yeah, setting teams up for success, requiring that they have all the bits that they need, is absolutely key. I think there is to play this back in the other way is the key elements of the agile thought process, and thinking through problems in a way that you are iterating, experimenting, understanding and learning in complex environments is absolutely key, regardless of the framework you decide to use it, and Scrum is a framework designed to help you learn how to do that. So that's where it fits in, but you've got to have the need to do that. So I think that's really where the parts come together. There. It's not one size fits all. Do this or nothing else it's thinking about. Do I have a problem where adopting this framework might help me get organized around solving that problem, and then that would give me a way of moving forward.
Dave:
I was just going to say.
Dave:
You said a couple of things, really interesting things, as you're describing that which is there's not only does Scrum, for example, very popular, very good framework to learn from, we also have to have the discipline to follow it. Because if you're going in with the iron mindset and we've all you know it's a bit like me using a recipe to cook a meal. I get the recipe for the idea, but then I don't follow the meal and I'm somehow blaming the recipe when it doesn't turn out the way it should have turned out. I don't follow. If I'm not disciplined about following the sort of framework, the directions, then I shouldn't be surprised at what I get at the end. It's not what I thought it would be.
Peter:
Right, exactly. So with that, you can send us feedback at feedback at definitelymaybeagilecom, and don't forget to hit subscribe, and I look forward to the next conversation. Until next time. Thanks again. You've been listening conversation today. Until next time. Thanks again, Peter.
