Could Agile methodologies be the villain behind developer burnout, or is it time to put the blame elsewhere? Strap in as Peter Maddison and David Sharrock pull back the curtain on the true antagonists in the saga of developer fatigue. This episode isn't about finger-pointing; it's about unveiling the systemic issues that lead to overworked teams and debunking the myth that Agile practices are inherently at fault. We're on a mission to shift the focus from flawed productivity metrics to the lived experiences of developers, advocating for a workplace ecosystem that values well-being as much as it does output.
This week's takeaways:
System Over Agile: Burnout in developers isn't caused by Agile itself but by systemic issues within the organization.
Curiosity Beats Assumptions: Prioritize curiosity over jumping to conclusions, as it leads to a deeper understanding of complex problems.
Experience Matters: Consider both developer productivity and experience, as focusing solely on productivity metrics may miss important qualitative aspects of developer well-being.
Join us on a thought-provoking journey as we dissect the nuanced relationship between leadership, incentives, and workplace behaviors. Far from a one-sided debate, we consider how effective leadership and the right organizational incentives can create an environment that not only encourages productivity but also ensures the sustainability of its workforce. Peter and David don't just skim the surface; they dig deep into the complexities that drive developer burnout and explore the intricate dance of factors that can make or break the health of a tech team. Tune in and gain insight into crafting a more supportive and resilient work culture.
We love to hear your feedback! If you have questions or would like to suggest a topic, please feel free to contact us at feedback@definitelymaybeagile.com.
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?
Dave:
Excellent, very good, and again, I think we're going to have to start recording our pre-podcast sessions, because I think we really do cover a lot of ground and some interesting topics.
Peter:
What do we call it?
Dave:
Definitely Maybe Agile, the good stuff, the outtakes or the blooper Outtakes, yes, but where did this one start? There is an article that is trying to tie developer fatigue and burnout with the fact that those developers are using Agile. Therefore, agile must be driving developer fatigue.
Peter:
Yeah, and we were chatting about this beforehand we went around quite a number of different windy avenues before kind of landing on a particular opinion with this, which is that you're looking at the wrong thing.
Dave:
If your developers are tired, it's because you've exhausted them, and whatever framework you use, Well, I think there was that little soapbox moment as well, which is how on earth can a methodology which is based on pulling work in cause developer burnout? If that really is the case they're pulling the work in then they would be able to pull the work in at such a rate to protect themselves from developer burnout.
Peter:
Yeah, I believe there's something in there about sustainable rate of work.
Dave:
I've heard it mentioned. Yes, so this was part of that. So then we get into that. Okay, it's not correlation, it's not causation. We have developer burnout on here. Over here, agile methodology is being used. The two do not necessarily. One is not necessarily the cause of the other potentially. Where did that lead?
Peter:
us. Well, that leads us down to the well, it's the system, it's the understanding, what's happening within that. But then we so one of the popular topics in the industry at the moment is about this comparing developer productivity versus developer experience, and there's been a lot of talk about this. There was a particular article that was published a little while back that said these are the things you should measure to measure developer productivity, and it got lamb-based at all across the internet and a lot of different places, and a lot of that is that this is idea that if you're measuring productivity, there's this natural connotation there that you are measuring the individual performance of the people and you're not. Instead of looking at like, am I building a healthy system that is supporting the people in it to do their best possible work, which is a whole other. What are you looking?
Dave:
at. Well, I think it's so even in our conversation. I mean one of the things when we read about some of these opinions and this sort of drawing together of A and B happening there for A must be causing B or whatever it might be, or that things like focusing on developer productivity over experiences is it's really easy to go in and say the leadership, the management, whoever is setting this up, is at fault, and yet, as you say, it's the system. We want to kind of almost take a step back again and understand that there is a system, there's some sort of metrics, incentives, reward mechanisms which are driving the behavior that we see.
Peter:
Yes, yeah, and then we sometimes and occasionally go on a bit about the necessity of leadership being at a certain place and it's and this leaders not being in that place that is what causes these initiatives to fail. But also we acknowledge that very often the incentives in the organization are what's going to drive that behavior. If there's nothing in it for the people to change, then they're not going to change you. It's like it's. If it's completely counter and in fact in some cases even detrimental to that leader to take the action which would mean introducing some of those changes, they're not going to do it. They're going to do what's quite, they're going to do what works for them and hopefully they're good leaders there and they're going to do what's good for them and the best they possibly can for the people that work for them. And if they're bad leaders, they're probably just going to do what's the best for them. But that's a whole other.
Dave:
Well, and I think the, as we're talking about that, developer productivity versus experiences another sort of frame to look at or another perspective to look at, which is we're now in an environment where everything is counted, where I've had a number of conversations this week and last week and the amount of data available to businesses to make their decisions and see what's going on is incredible compared to where it was before, and I think that whole there's developer productivity is about data. I can count what it is they're doing.
Peter:
Developer, experiences.
Dave:
Is that the sense making piece? And I came across a lovely little snippet of Jeff Bezos talking about when your data doesn't match your anecdotes. It's normally anecdotes which are real and I think that's a really it's a bit of a reminder to say these are complex systems and we might think we're measuring something, when actually we're measuring proxies for what we're looking at and so on, and so the fact that we can get charts and data and numbers that move up and down and so on gives us a false sense of security, and leaders, I would argue, should continuously be searching for and sort of gathering anecdotes and narratives and that's like to back up the data that they're seeing.
Peter:
Yeah, I mean. My favorite example of that from my career has been looking at operations data from service desks and seeing that from the data, like we've met all of our SLAs. All of the tickets were responded to within the SLAs. Everything looks absolutely fantastic. The data is absolutely clean.
Peter:
You look at what you go talk to the customers of the service desk and they're like it took forever to get a response. We had to go through multiple tickets to get the stuff that I needed. There were it was the. The person didn't didn't communicate well with me. It was like firing off a ticket into a black box and I never heard a game. And you're like looking again, ok, well, something's up here. Like the data doesn't match the anecdotes, and I'm always much more whenever I see that. It's like, despite some of the stuff I was working with in city, for the data says there's like, well, no, we got to go listen to our customers, like they're clearly not happy and so let's work out why and look at what are the underlying causes of that and see if there's any trends or understanding we can draw from that to improve our service delivery.
Dave:
So I think maybe, as I, we're jumping around a little bit again, but the thing that never happened before. But what I was going to say is there's starting with that first article about the sort of agile is causing developer fatigue, developer burnout. There's an element of if you know anything about agile, you know it's about sustainable pace and pulling work and so on. So there's definitely, if that is happening and you're still getting developer burnout, how do you go and look into that? How, what is being measured, what is being looked at? But I think the thing that kind of catches my mind's attention as we're having this conversation is the value of curiosity over jumping to a potential solution.
Peter:
Yes, yeah, and that's we touched on this last time as well is this you need to give space to understand the problem before diving in and making assumptions about what the solution is, because otherwise you will end up solving the wrong problem and, for example, solely relying on the data without going into talking to anybody may lead you down the wrong path. So you need to more fully understand what is happening here and there is, I mean, it's true to say that if in a system that's operating under a model where people are pulling in, work and they're working through it as a state of mind and we can see and understand it, then being burnt out shouldn't be happening. However, there are a lot of other incentives and drivers in the system that are presumably or probably driving other types of behavior in there, if that's what you're seeing. So there's something happening there and something failing.
Dave:
Yeah, no, that's very true. So wrapping things up so you talk me off the soapbox when we're talking about agile is causing developer burnout.
Peter:
Well, I think one of the key pieces that I have here is that it's about the system. It's not about agile, it really isn't. It's about the system work. If you're people and think of them as people are getting burnt out, then what is causing that? And it isn't agile, it's the system that you have in place that is causing your people to get burnt out. So look at the system and understand why that is. I think that is an absolutely key piece.
Peter:
I really loved what you were saying, too, about having curiosity, like being curious, not taking what you see at sort of first glance and saying, okay, that must be what it is being curious and asking questions and understanding what is the underlying problem, because these are often complex problems, lots of moving pieces, so we need to understand what might be doing this. Where are the stresses coming from? What's causing that in the system? And I think the third piece that we were talking about there was that if the agile is a pull-based system is most likely not a problem. It probably means you don't actually have an agile system. So that's kind of the piece that goes together. What would you add to that?
Dave:
You know, I think the only, and I think you summarized it really well. But the only thing that I would add is you introduced the idea of developer productivity versus experience and I think that's so underrated. I mean, we all want to work in organizations and places where the experience is exceptional and I think sometimes that really resonated. I'm going to dig more into that. But that whole idea of developer productivity versus experience and what that means in how you treat, how you measure, how you view your development, community, people in development.
Peter:
Coming up next week on Definitely Maybe Agile.
Dave:
So if you want to follow that, I think the intention there would be subscribe, share with your friends, bring comments along, as always. Just let us know what you'd like us to talk about. Yeah.
Peter:
And we were happy to explore topics. So thank you as always, dave, and until next time. Until next time, thanks again. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.