7 Deadly Sins of Agile: Greed

So one of the civil and deadly sins of Agile is greed, and this usually manifests in organisations by an overwhelming focus on resource utilisation. Let’s get rid of the fact that we’re calling everybody resources as if they’re cogs in a machine rather than actual people, right? But that focus on resource utilisation was a fantastic idea when we were running machines, and machines could churn out things on a regular cadence. We were able to— the more your machine is running, the more value you’re getting in return for the cost of the machine and the cost to run it, right? That’s where that resource utilisation idea comes from.

But when you start looking at people and how people do work, people need thinking time. People need to do things in different ways, right? If we can automate stuff that we do the same all the time, but if we’re going to do something different all the time, which in my world background is as a software engineer, everything we coded was something new. Otherwise, we would have used an existing framework, right? So anytime you’re writing code, you’re doing something new. Anytime you’re building a product that doesn’t exist yet, you’re doing something new that’s never been done before, right? So when you’re doing those, even if it’s been done before by somebody else, it’s not been done before by you.

And when you’re doing that, you need to give people the space to be able to do things well, to be able to think about things, to be able to learn things, to be able to try things. And that means that people aren’t always 100% focused on the work that they’re doing. They’re doing other things while thinking about that work. Some examples maybe— have you ever been working on something and got stuck? And the only way for you to get unstuck, no matter how much time you spent on this thing, you were stuck, right? You’re 100% utilised because you’re working on this thing, but you’re not making any progress. You’re not delivering any value.

But if you just go out for a walk, right? Or you sit with your wife and you explain the problem to your— I do this all the time. I explain some problem to my wife, and she doesn’t necessarily understand the problem that I’ve got, right? I’m talking about code and architectures and things, and halfway through explaining it, I figured out what my problem was, right? Because I knew I just didn’t have a moment to look to the side. I don’t know if that makes sense— like an out-of-body idea experience, an out-of-body experience, and look at that thing from the outside.

So that resource utilisation is a fallacy when you’re talking about people. There’s no such thing as resource utilisation. You want to be looking at flow efficiency and value delivery. How much value are you delivering to your customer? And I actually— I don’t care if my team members are sitting around on their butts for 90% of the time, as long as we’re delivering the value to the customer, right? The value to the customer is the important thing. Is the customer happy? Are we getting an adequate return on investment for our product? Those are the ideas that make sense.

I worked with somebody years ago who ran a little experiment with some teams that he worked with in a company in the US, and he decided to—or got convinced leadership that per sprint he would remove an hour from each sprint. So you can imagine you’ve got a 40-hour week per week per sprint. You’ve got a 40-hour week. The next sprint, he’s going to do a 39-hour week with the team, and the sprint after that, he’s going to do a 38-hour week with the team. And the sprint after that is going to do a 37-hour week with the team. And I’ve got a question for you: at what point do you believe that value delivery suffered if the focus is on value delivery, delivering features?

Now, that doesn’t mean that for the other two hours people aren’t— the hours that you remove, people aren’t actually working, right? If you think about it, a scrum team, somebody who’s focused on solving problems works 100% of the time, right? When I’m having a shower in the morning or when I’m— I actually do a lot of my best ideas at the gym. I go to the gym, I’m working out at the gym, and I go, “Oh, that’s a great idea,” and I go on my phone and I message it to myself, right? And then the next idea pops in how to solve problems and figure these out is not something that you get from 100% utilisation. You need thinking time.

So can you guess where he got to? He got to 16 hours per week before value delivery started to suffer because all the rest of the time is thinking time that the team needed— thinking and then noodling time. So very much stop being greedy. Stop trying to get people to maximise their utilisation, and instead focus on maximising the flow of value delivery to your customers.

Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else Agile, Scrum, or DevOps, then please book a coffee with me through Naked Agility.