10 Things I Hate About Agile: Part 1
This is the first half of a 2-part post describing 10 things I hate about agile. This half contains the first 5.
A confession
I should open by confessing that I actually really like agile. In fact, my job is to support people and teams across my organisation to adopt an agile way of working. However, like anything else, it comes with its problems. I’m going to talk about 5 of them in this post.
Reflections and romcoms
2020 gave a lot of people a lot to think about. One of the subjects that kept going around in my head was the role of agile in digital transformation.
I’m agile lead at Cancer Research UK. We’re a large healthcare charity that has been on a journey of digital transformation for some time now. Like so many other organisations across the world, Cancer Research UK is made up of a bunch of people who are readjusting to the latest manifestation of our enforced digital reality.
2020 also gave many people more time than they were used to, myself being one of them. I had plenty of thoughts about agile and the part it plays in digital transformation, but I wasn’t sure what to do with them. Cue a Christmas spent watching romcoms and a fateful viewing of 10 Things I Hate About You, the 1999 teen romcom take on Shakespeare’s The Taming of the Shrew. In a sudden flash of inspiration, I started to wonder if I could find 10 things I hate about agile.
And so, what you have before you is a set of problems that I have grappled with and learned about over the course of my career as an advocate for digital transformation and as an agile enthusiast. In this first of 2 posts, you’ll find the first 5 things I hate about agile.
“There are so many different ways to hate. Count them yourself. How do I loathe thee? Let me count the ways.”
1. Should I write capital ‘A’ Agile or small ‘a’ agile?
The first thing I hate about agile/Agile is that I never know whether I should write agile, or Agile. I talked to 3 people about this challenge before I published this post and they each had a different view about the ‘right’ way to do it. I need to get this one out of the way first, otherwise it will plague me throughout this post.
Let me explain. Written with a small ‘a’ and outside of the context of software development, the word agile generally means that something is able to move quickly and easily. It denotes flexibility, and a lightness of movement. It’s synonymous with nimble. You might use it to describe a squirrel leaping from branch to branch in a tree, or a gymnast in action.
Capitalise it, however, and this seemingly innocuous little word takes on a whole new meaning. Capital letter Agile inspires courage in the hearts of some, loathing in the hearts of others and feelings ranging all the way from bewilderment to indifference in everybody else.
At its core, Agile is an approach to work. It is a set of principles and values that characterise a way of working. It was originally designed to make it easier to develop software. It turns out it applies way beyond the world of software development. It also has a number of associated frameworks. Ultimately, it’s supposed to help teams to work together; to become more efficient, be user-centred and better equipped to manage risk in a world where so much is uncertain.
To me, what’s intriguing is that the first type of ‘agile’ I describe, the one with the small ‘a’, doesn’t actually preclude capital ‘A’ Agile. If your team starts to adopt the principles from the Agile Manifesto, it should mean that they can move more quickly and easily. They should become more flexible in the sense that they can respond to new information, change course and reprioritise. I’ll say it — Agile teams should be more agile.
And yet. Whenever I write the word, I second-guess whether or not I should capitalise it. If I write it with a small ‘a’, will people realise I’m referring to an existing and specific set of principles and practices? Will they think I’m talking about gymnastics? If I write it with a capital ‘A’, will people think I’m taking myself a bit too seriously? Or will I confuse them? Will anyone even notice?
I don’t know what the best answer is. However, what I do know is that we shouldn’t let it get in the way. So, whether you’re talking about agile or Agile, the most important thing is that you and whoever you’re speaking to understand each other. And if, like me, you spend a lot of your time trying to help people understand what it means to work in an agile/Agile way, and to give it a go, you definitely shouldn’t be precious about it.
For the rest of this post, I’ll follow my heart and I’ll write agile with a small ‘a’, unless I’m using it to start a sentence.
2. All of the agile jargon
Here is a non-exhaustive list of examples of agile jargon: ceremonies, epics, sprints, stand ups, Kanban and Scrum (kanban and scrum?!), user stories, scrum master.
If you haven’t come across these words before, they don’t make sense on their own. You can’t understand what they refer to just by hearing them or seeing them used.
At this point, I want to make an explicit distinction between agile ways of working and agile frameworks. (See point 3 for more on this). The words I’ve listed out here relate to agile frameworks. This is different to what I mean when I’m talking about people, teams and organisations being agile in terms of their mindset, their culture and how they work.
Don’t get me wrong, I get it. These words have specific meanings and they’re useful when you are working with a group of people that understand them, because they allow you to be really clear about what you’re referring to. That’s how language works! They were new words for new concepts, and they’ve helped to create an identity around agile ways of working.
However, I have spent a lot of my career introducing the principles and practices of agile to teams that have never heard of it before. When you start saying these words, at best people might think you sound a bit silly, at worst you alienate them completely.
Having a shared language is vitally important for groups of people to be able to make progress together. The lingo can quickly get in the way of that. The way I’ve overcome this is by making sure I’m able to describe the different aspects of agile frameworks in plain language, starting there and not getting offended if people want to roll their eyes or have a bit of a giggle about it.
3. When being agile gets confused with using an agile framework to manage your work
In point 2, one of the agile words I mentioned was ‘ceremonies’. With words like that in play, it doesn’t take much for people talking about agile to start sounding like they’re part of a cult.
Picture this. You’ve just started working with a group of people whose job is to convince the very best scientists out there to come and do research for Cancer Research UK. They’re a team of writers, editors and marketing specialists. They write stories and information and they put it online. They care about understanding their audience and they want to be able to respond to their needs quickly and effectively. They’ve never heard of agile until now (why would they?) but they’re willing to give it a go. It’s all going swimmingly until you start inviting them to ‘ceremonies’ and asking them to talk about their feelings in ‘retros’.
I’ve seen it a lot of times — sometimes agile enthusiasts can get a bit dogmatic. Suddenly, being agile turns into working in Scrum and the Scrum guide becomes a set of rules. Before you know it, you’ve lost sight of the guiding principles and values that characterise working in an agile way.
The problem with that is, when you prioritise the process over the principles, agile turns into something you can do right or wrong, and it completely misses the point.
What I’m trying to say is that adopting an agile way of working doesn’t necessarily mean adopting an agile framework. Working in Scrum or Kanban doesn’t make you agile. Doing daily stand ups doesn’t automatically make your team transparent and open; holding a planning session every 2 weeks doesn’t necessarily mean you’re able to react quickly to new information.
What’s important is that you start with the principles that matter to your team and build out your behaviours and practices around that. Happily, you don’t have to start from scratch. You can use the existing and defined agile principles, frameworks and practices as a starting point. You’ve just got to make sure you all understand why you’re doing what you’re doing and that you have a mechanism for reflecting and improving how you work as you go along.
What I hate is when we lose sight of the point of being agile and forget that being agile is a means to an end, not an end in and of itself.
4. When being agile gets confused with using a particular tool or set of tools to manage your work
I feel like I’m cheating a bit here, because this point is very similar to my previous one. However, I think it’s worth acknowledging that getting fixated on a tool is a separate thing I hate about agile.
In both cases, when you equate being agile to adopting an agile framework or using a certain tool, you miss the entire point of the agile principles. In the same way that adopting Scrum doesn’t make you agile, using JIRA does not make you agile. Using Trello does not make you agile. Using Slack does not make you agile.
All too often, I’ve seen people fixate on a tool and assume that using it will invoke an automatic leaning to agility in their teams. I’ve done it myself! If we can just get everyone in a Slack channel, then they’ll start talking to each other. Oh! No-one’s posting anything? I’ll @ the channel. Still nothing? Okay, let’s at least get the work on Trello, then everyone will see it and be able to understand it. Hm, no-one’s moving cards. What now, JIRA?! And so on and so forth. There’s no shortage of tools out there.
Again, you need to start by understanding what’s important to your team. What will facilitate their ability to understand each other, talk to each other and know when they need each other’s help? Then you take it from there.
So, why did I include this as separate point? Because, crucially, there is often a difference in how empowered you are when you’re making decisions about your teams’ principles and practices, and when you’re deciding on the tools you use to help you get your work done. Traditionally, tool usage is governed very differently within organisations.
Which tools you’ll use often involves consideration of things like information security, cost, how to procure it, legalities and flow and storage of data. You’ve also got to think about what tools everyone else is using, so that you don’t inadvertently start creating information silos. Ultimately, you might find when it comes to tools, you’ve got a bit less freedom.
When this is the case, you need to be open minded about making things work, using whatever you have at your disposal. You might not get the tool you wanted, but whether or not you’re enabling your teams with the right tools is another conversation entirely. My point today is that if you only believe that you can achieve agility by using a certain tool, you’ll limit your ability to be truly agile, irrespective of whether you’ve got access to that tool or not.
5. Agile by itself isn’t enough
Something else I’ve noticed over the course of my career is that it can be hard to keep sight of agile as just one part of a wider ecosystem of principles and practices. I think there are 2 main problems that occur when this happens.
The first is that you forget that there are other helpful — and important — practices out there. I spend a lot of time in my job advocating agile as just one piece of the puzzle of achieving effective ways of working and digital transformation. I make a point of talking about it in relation to other approaches which I think are fundamental, like human-centred service design, design thinking and Lean StartUp. I do that because I believe you need more than just an agile way of working to deliver great products and services.
The second problem is when a fixation on agile as gospel gets in the way of people being able to find common ground. Even if you’ve managed to escape the trap of confusing being agile with adopting an agile framework (see point 2), if you can’t see beyond the principles of agile to understand and explore principles from other approaches to work, you’re really missing out.
Take this, very current, example. Lots of large, complex organisations have started talking about the need to be agile with renewed vigour as a direct result of our new, enforced digital reality and the general disruption caused by the COVID-19 pandemic.
But what do they really mean? If your organisation is anything like mine, it means that we want to get better at navigating ambiguity, managing risk and delivering high quality products and services with less waste and increased efficiency.
So, if any part of your job is about supporting people to work in an agile way, don’t be fooled into thinking that just ‘being agile’ will be enough. Yes, taking the time to understand the agile principles and adopting practices that help you to live them in your work will help you. But don’t forget that there is so much more out there and these approaches are not mutually exclusive.
To be continued
So there you have it, 5 things I hate about agile. From how you write it, to how you explain what it is. From getting distracted from the point by agile frameworks and/or the tools you use, to losing sight of the bigger picture. These are 5 things about agile that I’ve seen get in the way of positive change and digital transformation.
In the second of these posts, I’ll talk about 5 more things I hate about agile, including agile tribalism and the us vs them mentality it can engender, scaling agile and how vulnerable agile is when it’s just getting started.
And now, all I need to do for everything else that’s on my mind, is watch another romcom. How about My Big Fat Sprint Backlog? Could there be something in How To Lose A HiPPO In 10 Days? Or, what about my personal favourite: When Harry Met Sally, and they achieved success by forming a psychologically safe cross-functional team?
