One of the seven deadly sins of Agile is sloth, and I’ve seen it manifest in various ways across teams, organisations, and leadership. It’s a pervasive issue that often goes unnoticed, yet it can severely hinder our progress towards true agility.
When we say we’re doing Agile but fail to deliver working products at the end of each Sprint, we’re not just missing the mark; we’re being lazy. Here are some common signs of sloth in Agile practices that I’ve encountered:
1. Failure to Deliver Working Software
Are teams delivering working software to real users every iteration, including the first? This is the essence of Agile. If you’re not getting ideas in front of customers and gathering feedback, you’re not doing Agile. It’s as simple as that.
2. Lack of a Product Charter
Is there a product charter that lays down the mission and strategic goals? Do all team members understand how they contribute? Without this clarity, how can we expect our teams to make informed decisions? We’re hiring smart, capable individuals, yet we’re not empowering them with the information they need. If communication is lacking, that’s sloth.
3. Ignoring User Feedback
Are you turning feedback from users into concrete work items on Sprint timelines shorter than one month? Engaging with customers and getting parts of your product in front of them shouldn’t be a Herculean task. If you’re not doing this, you’re being lazy.
4. Bureaucratic Deployment Processes
The full ecosystem of your project should be Agile. If you have Agile programming teams followed by linear bureaucratic deployments, you’re failing. It’s crucial to get the working product in front of users quickly to close feedback loops and validate assumptions. If it takes too long to deploy, you’re not being Agile.
5. Inability to Change Requirements
Are teams empowered to change their requirements based on feedback? The people doing the work should have the authority to adapt the backlog as needed. If your organisation insists on sticking to a rigid list of requirements, that’s fundamentally not Agile. Welcome changing requirements, even late in development.
6. Resistance to Process Change
Finally, are teams empowered to change their processes based on what they learn? Agile is about emergent practices and continuous adaptation. If senior leadership is unwilling to allow teams to evolve their processes, they’re missing the point of Agile.
These six indicators embody sloth in Agile. If you’re not able to do these things, it’s a sign that you’re not genuinely interested in moving towards agility. It’s time to get off your arse and fix it.
In my experience, honesty and transparency are crucial. If your product isn’t suited to Agile, or if your organisation’s structure is holding you back, it’s better to acknowledge that than to pretend otherwise.
I highly recommend checking out the article “Detecting Agile BS” from the US Department of Defense. It’s a fantastic resource that outlines these issues and provides a workflow for addressing them.
If you found this discussion valuable, please like, follow, and subscribe. I always welcome comments, and if you’d like to chat about Agile, Scrum, or DevOps, feel free to book a coffee with me through Naked Agility. Let’s work together to overcome sloth and truly embrace the Agile mindset!
One of the seven deadly sins of Agile is sloth, and this manifests in a number of different ways with teams, with organisations, uh, with leadership all over the place. Um, one of the most common elements is just not bothering our ARS, actually doing the things that we say we’re going to do. Right? 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, um, but we have long convoluted deployment processes which are not in control of the developers. We say we’re doing Agile, um, but we don’t have an ordered backlog. Right? 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 to not 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. Um, 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.
Um, I really like there’s a great article called “Detecting Agile BS” from the US Department of Defense, and 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. So here are six sloths, uh, things that organisations kind of say they do, um, or pretend that they’re Agile, but they don’t actually do these things. Uh, and this, I think these are great.
So, the first one is: are teams delivering working software to real users every iteration, including the first, and gathering feedback? That’s like the first thing. 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. Right? You’re not able to get things done.
Uh, the second one, and because this is the Department of Defense, right, is: is there a product charter laying down the mission, strategic goals, and do all members of the team understand how they contribute? Right? 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? Right? We’re hiring smart, clever people, and then we’re not empowering them to do the things that they need to do. Right? We’re just not empowering them.
Um, and that’s part of we need to communicate with them, and if you don’t communicate with them, sloth. If you don’t actually do those things, you’re being lazy. Right? Just do it.
Uh, the third one is feedback from users turned into concrete work items, um, on Sprint timelines shorter than one month. Right? So, are you getting things in front of your customers at least once per month? Um, and those… that shouldn’t be that hard. Right? 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. Right? Gathering feedback from those users, that shouldn’t be that hard, and if you’re not doing it, sloth, because it’s not that hard, you’re just being lazy.
Uh, one that I already mentioned a little bit is the full ecosystem of your project Agile, i.e. Agile programming teams followed by linear bureaucratic deployments is a failure. Right? Why do you have linear bureaucratic deployments after your Agile team have done the work? Yeah, 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? And 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.
Um, that should be the case. And then 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. And if you’re not doing that, sloth. Right? 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, yeah, we want to get all the benefits, oh, 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.
And then the last one, on the Department of Defense, you know, not well known for being an Agile organisation, but um, the last one on their list is: are teams empowered to change their process based on what they learn? So, not only changing the work that they’re doing, but changing the way that they’re doing the work. And 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. Right? And without those abilities, we can’t do that.
That I feel like these six things absolutely embody sloth. Right? 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 arse and fix it.
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.
