Agile is hard and it’s designed for complex environments. So, as you would expect, there are many behaviours that I’ve found in organisations that are suboptimal, to say the least. Here are my seven deadly sins of Agile.
Hi, I’m Martin Hinwood, owner and principal consultant at Naked Agility. I’m a professional Scrum trainer with Scrum.org, a professional Kanban trainer with Pro Kanban, and I’ve been a Microsoft MVP in GitHub and Azure DevOps for 15 years.
One of the seven deadly sins of Agile is lust. Loads of organisations are talking about Agile transformation, digital transformation, whatever transformation. They want something different because they’ve realised that the markets have changed. It’s taken them a long time to realise the markets have changed. They changed years ago. In fact, the 1930s was when the market started to change. By the 1970s, they were totally changed, and it’s taken until now for a lot of companies to actually realise, “Oh, stuff’s changed. What’s going on? Why isn’t our old processes and systems working?” So now they’re looking around for something new. They’ve got that, I was going to say, “70-year itch,” but it’s the 70-year itch, and they’re looking around for new processes and practices that they can use. They see this Agile thing doing really well, and they want it. They want it desperately, and they don’t really want to do the work for it. They just want to buy it. I think there must be a USism for that, but I think I’ll stay away from it. They just want to buy this thing; they don’t want to actually spend the effort and the time and the energy to figure out what it means for them and their business. They just want somebody else to come in and install it. They just want to pay somebody to come in and do it for them. That’s what they want to do.
That’s why you see a lot of organisations bringing in the big four consulting companies. You see McKinsey, Accenture, and Boston Consulting Group coming in, giving advice. But the problem is they’re giving advice based on all of these other big organisational transformations. There is no precedent within your organisation for Agile. You can’t just look at what somebody else is doing and lust after it and bring it into your organisation. You need to build your own unique way of doing things over time and actually do the work to get there. That’s why you can’t just lust after this Agile thing; you need to do the work to bring it into your organisation.
One of the seven deadly sins of Agile is gluttony, and I see this a lot in teams where their backlogs and their products become bloated and full of basically just full of crap that needs to go. One common entry is the product backlog. If you go into a team you’re working with and you look at their product backlog, and let’s say there’s six or seven people working on this team and they have 5,000 things in their product backlog, they’re doing it wrong. That’s greedy. They’ve eaten all those backlog items; they’re sitting in their belly and they can’t walk around. They can’t move; they’re not going to be nimble. They’re not going to be Agile because it’s almost impossible to understand what is our value, what value is in our product backlog. Diving into that thing is just not a good idea. You’ve got too much stuff in your product backlog.
Another way gluttony manifests is during Sprint planning, shoving more stuff into the Sprint backlog than the team can possibly deliver in a single Sprint. That continually results in the team having to vomit backlog items into the next Sprint. If you think of it that way, perhaps teams will stop doing it. Taking on too much and then it spews into the next Sprint. If it’s one or two things that move into the next Sprint, maybe not every Sprint is probably okay. You’re not going to be successful in everything you do, but if you’re constantly got tons of things from a Sprint flowing into the next Sprint, flowing into the next Sprint, perhaps there’s a need to consider, “Are we taking on too much work? Are we doing too much? Are we taking on too much work?”
That’s the second form of gluttony that I see in teams. The third form is leaving stuff that nobody uses in your product. The Standish Group in Boston used to create the Chaos Report every year, and they analysed about 70,000 projects worldwide. They found that only 35% of the features that we build are used by our customers. 65%, I think the phrase was, “Ed little if ever.” So hopefully we can stop building them in the first place. That would be great. Let’s stop building them in the first place. But if we have built them, why are you keeping them in your product? Why are you continuing to spend maintenance hours on support? How long does your build take? How long does your build take if you remove 65% of the code that’s in your product? Because you’ve got rid of those features, your build would be faster. Your teams will be able to work faster. There’s a less complicated body of content. You’ll just get better and faster at doing things.
So the way to… loads of teams just need a gastric bypass for that. How do you restrict the amount of stuff that’s in a product? That’s really hard because that’s much harder than backlog or Sprint backlog. It’s to figure out what percentage of the features of your product are actually used. The worst is continuing to invest in features that are of no use, features that aren’t used by your customer. I guarantee you loads of teams do that. Years ago, I worked with a bank in Boston, and they were absolutely adamant that this 65% was crap and they knew their customers way better than anybody else. There was no way they were wasting 65%. It was a lot less, that’s what they said. So we said to them, “What’s your flagship product that you build? What’s the product that you think you know your customers best and are building all the awesome features?” They said, “This one, this one’s the best.” So we got in amongst the code, we added application insights. Application insights is an Azure feature that can be plugged into any application anywhere, which basically collects data. It supports all the programming languages, all the setups, and out of the box it does a bunch of stuff. But then if you add this as a feature, you can say, “How many times do users click that button of our body of users? How many of them have clicked that button?” You can get all of that data.
We analysed their product end to end, so we collected data for three months, and then we went back to them and said, “Here’s the 7.5% of features that your customers use. All the rest was waste.” Over 90% of the money they invested in their product was waste. What was really interesting was that more than 80% of the items in their backlog at the moment were going towards additional capabilities for features that weren’t used by their customers. So no, don’t eat the whole thing. You’ve got to figure out how do I pick and choose what I’m going to eat. Don’t eat the whole feature at once. You don’t know if you like haggis yet, so don’t order a whole plate full. Get a starter that’s got a little bit of haggis and try that first. Then, obviously, when you realise you do like it and your customers like it, then you can make more. But don’t overeat on your product backlog. Don’t overeat in your Sprint backlog, and don’t overeat in the features in your product.
One of the seven deadly sins of Agile is greed. 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. That focus on resource utilisation was a fantastic idea when we were running machines, and machines could churn out things on a regular cadence. 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. 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 different ways. 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 as a software engineer, everything we coded was something new. Otherwise, we would have used an existing framework. 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. 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. 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? No matter how much time you spent on this thing, you were stuck. 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 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. I’m talking about code and architectures and things, and halfway through explaining it, I figured out what my problem was. 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 experience and look at that thing from the outside.
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? I actually 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. 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. He decided to, or got convinced leadership that per Sprint, he would remove an hour from each Sprint. 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. The Sprint after that, he’s going to do a 38-hour week with the team. The Sprint after that, he’s going to do a 37-hour week with the team. 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 actually working. If you think about it, a Scrum team, somebody who’s focused on solving problems works 100% of the time. 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. 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.
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 noodling time. 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.
One of the seven deadly sins of Agile is sloth. This manifests in a number of different ways with teams, with organisations, with leadership all over the place. One of the most common elements is just not bothering to actually do the things that we say we’re going to do. We say we’re doing Agile, but we don’t deliver working product at the end of the Sprint. We say we’re doing Agile, but we have long convoluted deployment processes which are not in control of the developers. We say we’re doing Agile, but we don’t have an ordered backlog. All of these things are places where we say we’re doing something, but really we’re just kind of lazy and lying through our teeth in order not to have to do the work. Perhaps it’s because somebody in leadership in the organisation has decided that thou shalt do Agile, and your product is not particularly suited to that model because it was built in a traditional… maybe it’s got mainframe and all kinds of crazy stuff in there. Maybe there are other reasons why it’s not viable within the confines, the structure of your organisation, the system that you’re in. But I would much rather teams and people were honest and transparent with their companies and their organisations about what they can and cannot do, what is and is not Agile.
I really like there’s a great article called “Detecting Agile BS” from the US Department of Defense. If you search for it, you will find a great little workflow on it. It’s one of my favourite things that I use in organisations. Here are six sloth things that organisations kind of say they do or pretend that they’re Agile, but they don’t actually do these things. I think these are great. The first one is: are teams delivering working software to real users every iteration, including the first, and gathering feedback? That’s almost Agile in a nutshell. Are we coming up with ideas, getting those ideas in front of customers, and getting that feedback? If you’re not doing that, sloth. You’re not able to get things done.
The second one, and because this is the Department of Defense, is: is there a product charter laying down the mission, strategic goals, and do all members of the team understand how they contribute? That’s absolutely key. How can we expect people within the context of our product, of our teams, of our organisation to make good decisions about what it is that they need to do if they don’t have all the information they need? We’re hiring smart, clever people, and then we’re not empowering them to do the things that they need to do. We’re just not empowering them. That’s part of we need to communicate with them. If you don’t communicate with them, sloth. If you don’t actually do those things, you’re being lazy. Just do it.
The third one is feedback from users turned into concrete work items on Sprint timelines shorter than one month. Are you getting things in front of your customers at least once per month? That shouldn’t be that hard. It shouldn’t be that hard to engage with your customers, get parts of your product in front of your customers, and then get them to tell you what they think of it. Gathering feedback from those users shouldn’t be that hard, and if you’re not doing it, sloth, because it’s not that hard. You’re just being lazy.
One I already mentioned a little bit is the full ecosystem of your project. Agile programming teams followed by linear bureaucratic deployments is a failure. Why do you have linear bureaucratic deployments after your Agile team have done the work? We might be able to make working product in two weeks, but how long does it take before that increment, that two weeks’ worth of work, actually gets in front of real users so that you can close those feedback loops, break down those assumptions, validate what it is that you’re creating, that it is actually value? If that’s too long, that’s not Agile. If you look at the Agile Manifesto, it says ideally a shorter time frame, but only a few months between having an idea and getting it into production.
The fifth one: are teams empowered to change their requirements based on feedback? The people doing the work should be able to change and adapt the requirements that they’re creating in the system, the things that they’re building. We want to build more of the right things and less of the wrong things. We want to maximise the amount of work not done. All of those things require the people doing the work to be able to delete, add, or change things from the backlog as needed based on those interactions that we’ve already talked about with the customer. If you’re not doing that, sloth. Why are you not doing that? Why is somebody not addressing the problems of why you can’t do that? If your organisation is saying we want to do Agile and we want to get all the benefits, but you can’t change your requirements, you have to do everything that… here’s the 300 things we need you to do. That’s fundamentally not Agile. Welcome changing requirements, even late in development. These are just fundamental principles of agility.
The last one on the Department of Defense, not well known for being an Agile organisation, but the last one on their list is: are teams empowered to change their process based on what they learn? Not only changing the work that they’re doing, but changing the way that they’re doing the work. Why aren’t your teams empowered to do that? Well, because people more senior can’t be bothered with that. They just want to buy Agile from some vendor, install it, and then everybody just does it that way. That’s not fundamentally how Agile works. Agile is about the emergent practices, the continuous change, emergence, and adaption of our processes, practices, and tools in order to be able to maximise the value delivered to the customer, the stakeholder, which may be the business themselves. Without those abilities, we can’t do that. I feel like these six things absolutely embody sloth. If you’re not able to do all of these things, you’re not really that interested in moving towards agility. You’re really not that interested in doing those things. It’s lazy. It’s inept. Get off your ass and fix it.
One of the seven deadly sins of Agile is wrath. Wrath occurs in many different forms in teams working in organisations. Most often, it’s the inability for us to do things wrong. It’s the inability for an organisation to accept that we’re not going to do things right every time. This can kind of manifest in an example from recently. We need to work with an organisation; we need to create some procedures and practices around doing a deployment. We need to create procedures and practices, and the team that I’ve been working with wants to create, “Here’s what we think is going to work. Let’s try that, and then as we figure out more, we can iterate on this policy and procedure and get it to be what we need it to be in order to be successfully in production.” Then we can reuse that as we go for future applications, right? Future things that we’re doing. But the other side didn’t want to do that. They wanted to create your final draft, we’ll take that, we’ll run it around the 100 people that need to go see it, and we’ll create a spreadsheet with all of the things wrong with it. Here are the things wrong with it that you have to go fix before we can approve it. That approval process is wrath. You can’t be wrong; therefore, the end result needs to be approved before you can do it. Because if it’s approved, it’s now no longer your accountability, so we’re not going to blame you. It’s a blame culture technique. It’s going to run up the chain, get approved, and then whoever’s approved it at the top, it’ll be beneath them to solve the problem anyway. If something goes wrong, oh, it’s not the people down here’s fault because it was approved. Go up. Who approved it? Oh, the CEO approved it. Well, okay then. Well, it was wrong, whatever. There’s no accountability. A lack of accountability results in wrath going on in the organisation, and I think this manifests in lots of different ways. I think that’s the core thing, but it manifests in lots of different ways.
One of them that I’ve seen happen with a team was during a Sprint review. The team was demonstrating their product and features to the stakeholders, and one of the stakeholders asked the team, “Why did you build it that way?” in a kind of accusatory tone, like, “Why did you build it that way?” What I would expect to happen would be that the product owner would take accountability for the value delivered in the team, and they would get out in front of that and say, “Well, these are the decisions that we made. We can always go back and change them.” Blah, blah, blah. That’s taking accountability. But no, that’s not what they did. Wrath. They passed the buck, and the product owner turned to the team and said, “No, why did you build it that way?” That’s not taking accountability. I think wrath is a big reason I don’t want it to be my fault. It needs to be somebody else’s fault. Otherwise, something will land on me. I’ll get covered in the poop from the mistake that happens. I think that lack of mistakes is a huge part of that story. So don’t let your organisational culture of wrath create this environment where nobody will take accountability.
One of the seven deadly sins of Agile is envy. For me, I think envy in Agile looks like just copying other people’s stuff. That’s one of the ways it manifests. We believe that if somebody else is getting success with something, then of course we will get success with something. The difficulty is that that’s not necessarily true at all. I’m going to rephrase that. It might be. It might be possible on the small scale. You’re working with a team. One of your colleagues and another Scrum Master or another product owner is using a practice that they’re like, “Oh, this is great. We do this and this, and we have this value stream, and we’re able to get good stuff from that.” You’re like, “Okay, I’d like to try that.” That’s not really what I consider envy; that’s just trying stuff. Envy would be looking at a great example of envy: the Spotify model. The Spotify model is a fantastic example of envy. There is no such thing as the Spotify model.
There was a presentation and paper that a couple of folks that were leaders at Spotify did at a conference. I think they did a couple of conferences talking about what Spotify was doing, what their journey was, and where they currently were on their journey. They were telling an example of how they did things, and everybody went, “Ooh, the Spotify model! Let’s do that!” They absorbed that into their… “I want this capability,” and they go try and bring it into the organisation. But what folks don’t realise is six weeks later, Spotify were doing it differently. They weren’t doing what was defined in the Spotify model. A year later, they got rid of the idea of tribes and guilds and whatever else they were doing because it didn’t work for them. They tried something, and it didn’t work for them. That envy of, “Oh, they’re doing this awesome thing, so we need to be doing that awesome thing,” results in a lot of… it results in a lot of FOMO, if you’ve heard that expression, “fear of missing out.” I think that’s kind of part of envy. Other people are getting stuff, and you want the same stuff. That’s where, at many levels, organisations fail. They fail at the process level because you look at a Spotify model or you look at SAFe or you look at any of those big models and say, “I want that. I want to install that in my organisation.” Then you pay lots of money to get it installed and then wonder why you’re not getting the benefit.
There’s the application level. I talked about this recently on a podcast. Installing an application that enshrines somebody else’s business processes into your organisation is not necessarily going to be successful for you. The example I used before was SAP. SAP is a massive application tool, very common in our industry. If you adopt an SAP tool, SAP comes with a bunch of different capabilities. Let’s say it’s invoice processing. SAP has a workflow for invoice processing that comes out of the box. It has certain ways that it does things, and you’re giving up the way your organisation does things in order to adopt the way SAP does things. Does that kind of make sense? There are some things that you can adapt in SAP, but only within the bounds of what the developers that created it allow. This means that when you see some of your competitors perhaps installing SAP and building their whole procurement processes in SAP, you think, “Oh, we need to do that.” If they’re doing that, we need to do that. Or if our competitors are adding these features to our product, we need to add those features to our product. That’s envy. That’s following, not building your own path.
Simon Sinek does a great video on this topic, and he talks about the why. He talks about going to two conferences: one is a Microsoft conference under Balmer, and one is an Apple conference. At the Microsoft conference, everybody wanted to know what their competitors were doing. What are their competitors doing? What are their competitors saying? What are they launching? What features do they have? At the Apple conference, they didn’t give a crap about what the competitors were doing. They’re like, “This is the way we’re going. We’re doing this because it fits within our belief model.”
Generosity, comfort, confidence, contentedness, friendliness, goodwill, kindness, benevolence, friendship. Those are the opposites of envy, and I think that if you can put aside what everybody else is doing and focus on what you need to do and what your customers need, you’ll have a lot better time both in the process space, in the tool space, and in your organisational structure space.
One of the seven deadly sins of Agile is pride. Now, you do want to take pride in your work. We all want to do good things. We want to believe that the things that we create are valued. But I think the pride that’s the sin part is blind pride. You’re taking pride in something without actually measuring its outcome. We talk about this all the time for product owners. Don’t just build stuff willy-nilly. You need to collect the data, the telemetry, the analysis. You have to do hypotheses. You have to create the hypothesis: “I think this thing, if I build it, is going to add value.” You create it, and you don’t just assume that it’s going to make the value that you think it is. That’s pride talking. You need to analyse the data and figure out if that actually did provide the value you’re expecting. You need to stop investing in something that isn’t providing the return that you’re expecting it to do.
Another good example of that is Satya writing down the cost of Windows Phone, writing off Nokia for $8 billion. Sometimes you have to swallow your pride and not sink more money into something that’s not going to provide a return, and you just have to stop. I used to work at a bank in the UK near Edinburgh, and they created this massive piece of software that basically all it did was create forms for customers to fill out. But it was the most convoluted, unusable, unwieldy… I’m trying to think of more words to describe the ridiculousness of this software. It didn’t provide the features that they actually needed, but they’d spent $2 million on building it, so they must use it. We must continue to use it. That’s that sunk cost fallacy, which I think is very closely related to pride. While we’ve invested this much money, it must be awesome, so we must use it. Those are assumptions. I think pride is how come we assume stuff. We assume lots of things. The product owner assumes that the features, the ideas that they have are good ones. The market doesn’t always agree. Developers building things in a way that entertains them rather than that actually focuses on the value delivered to the business. I’ve been guilty of that many times, working on features because they were fun, not because they provided any value to the customer. I’ve done that a ton. You need to be really careful that you don’t become too prideful, making assumptions about the products and capabilities that you’re building, the code that you’re writing, the stories that you tell in such a way that it clouds your view of what’s really going on. Because then all you’re looking at is vanity metrics. You’re missing out on what’s really going on. So don’t be so prideful that you miss out on what’s really going on.
