10 Things I Hate About Agile: Part 2
This is the second half of a 2-part post describing 10 things I hate about agile. This half contains the last 5. You can read the first half here.
Let me (re)introduce myself
As I confessed the last time I wrote, I’m actually a big fan of agile. I’m the agile lead at Cancer Research UK and my job is to help people adopt agile ways of working. That’s why I spend so much time thinking about what the problems are with agile, and how to overcome them. I also like romcoms, which is where the idea for these posts came from.
In my last post, I talked about the challenges of knowing how to write it (agile or Agile?) and all the unintelligible jargon that often comes with it. I talked about how agile frameworks and the tools you use can get in the way of being truly agile. I also explained why I think agile ways of working in isolation aren’t enough. I believe an agile approach is much more effective when it’s combined with other approaches and methodologies like human-centred design and Lean Startup.
These are all problems with agile that I’ve seen get in the way of positive change and digital transformation. In this post, I’m going to talk about 5 more.
6. Wait, what do you mean when you say agile?
As I was getting ready to write this post, I reread my first one. It struck me that everything I’d talked about so far pointed at a major, underlying problem with agile which I hadn’t explicitly called out. It’s a problem I face every single day. I particularly dislike it because you often think you’ve solved it when in fact, it’s something I find myself coming back to again and again.
Agile is a word that means different things to different people. A bit like the word digital, or the term digital transformation. This problem underpins everything I’ve said so far, and everything I’ll go on to say in this post.
It got me thinking about my experience when I started in the agile lead role at Cancer Research UK. One of the first things I did was go and find out what people meant when they used the word agile. Understanding that helped me to figure out why people were and weren’t up for working in an agile way. It has also helped me understand why we want to work in an agile way at Cancer Research UK. Knowing that makes it easier for me and my team to set goals and understand the impact we’re having. It also means that agile ways of working are a means to an end rather than an end in and of themselves. That’s much more meaningful and motivating for everyone involved.
What struck me is that I know that agile is interpreted in different ways, but it’s still something I have to re-remember and revisit all the time.
7. Agile tribalism
I hate it when agile gets tribal; when it becomes us versus them.
I have seen this happen a lot. For example: agile vs waterfall (a project management methodology), agile vs ITIL (a set of standards for delivering IT services), agile vs corporate governance (a framework for managing cost and risk in an organisation).
I think this us-and-them mentality occurs when two things are true. The first is that there is a prevailing belief that agile ways of working are something that you can do right or wrong and that they are being introduced because the way we currently do things is wrong. I really dislike that narrative, because it makes people feel bad and it’s not what agile is for.
The second is that ‘getting it right’ has become more important than getting it done (‘it’ being the goals you’re aiming for in your work). It might be that ‘being agile’ has been reduced to meaning working in one of the agile frameworks. Or it might be that there are assumptions about what counts as being agile. Whatever the belief is, when this happens you’ve got a problem. Sides start to emerge. Unhelpful narratives develop about how ‘they’ are doing things. People align their professional identity with a methodology. Empathy breaks down.
This is all really bad news. It’s bad because the stakes are higher and more personal. When you’ve publicly committed to a side and the most important thing is being right, it becomes much harder to find ways of working well with other people who have a different perspective to you. And if, like me, your job is to help people to adopt an agile approach to their work in order to realise certain benefits that an agile way of working facilitates, you’ve basically got no chance.
All of this is literally the opposite of the point of agile. The Agile Manifesto is a set of principles and values that promote the importance of people, collaboration and being able to respond to change. It’s about building teams, practices and cultural norms that make it as easy as possible for you to deliver value to the people that use your products and services. In whatever way works!
In many respects, the noise around agile doesn’t make this easy. What with all the alienating language, the pervasive perception that it comes with a load of rules (via the frameworks) and the confusion about what it means, agile can make people uncomfortable.
I’ve found that an effective way of avoiding a descent into agile tribalism, or getting out of an us-and-them scenario if it already exists, is to focus on the outcomes we’re trying to achieve. Meet people where they are by building shared understanding. Start by identifying and agreeing your common principles and values (in case you were curious, the agile ones make a great starting point!). Build your ways of working together. Keep iterating on them together.
8. When agile ways of working get reduced to working really fast
Sometimes, agile gets misused and/or misunderstood as a way of making teams build and deliver tangible outputs really fast at the cost of being user-led. The problem here isn’t with doing things quickly, it’s with not de-risking what you’re doing with user research. This happens when user research is perceived as an activity that slows down delivery and/or the reason for doing it is not well understood.
Organisations want us to work as quickly as possible and humans are wired to want to see results. There’s something about agile that can enable these influences in an unhelpful way. Getting stuff out there quickly is an element of working in an agile way but reducing it to mean solely that is an oversimplification. Agile isn’t just about churning stuff out as fast as you can. Instead, it’s about getting in front of your users as fast (and as often) as you can; through talking to them, seeing how they interact with what you’re developing and getting their feedback. In the words of the Government Digital Service service manual:
You might think you know what they need, but you are not your user, so how can you be sure?
When you ask your teams to solve a problem for your users and give them the autonomy to learn and experiment with how to do that, you greatly increase the likelihood of them delivering the right stuff. There’s plenty of evidence out there for this, but let me illustrate my point with an example from my own experience.
An example: DIY fundraising materials
I was part of a team that was tasked with building a way for people to design their own fundraising materials online. We wanted to make it easier for our supporters to get on-brand materials to help them with their fundraising. We also wanted to reduce the pressure on our internal design team, who were spending a lot of time producing things like tickets and posters over and over again. The solution seemed obvious — if we built a way for our supporters to create their own fundraising materials online they’d get their materials faster and we’d save money on time spent designing.
We started by running user research interviews. We spoke to our supporters and the fundraising managers that collected their requests for materials and sent them to our design team. At the same time, we also ran a series of experiments online.
What we learnt was that the supporters who were in touch with a fundraising manager valued that relationship and the ability to plan their fundraising (including designing their materials) with a CRUK member of staff. They didn’t use the online tool that we had prototyped. They were happy with how things currently worked. In other words, their needs were already being met.
We discovered that there were people who would create their fundraising materials in this way, but this was a different audience. If we proceeded with building the tool, we wouldn’t solve the problem we had set out to solve. In fact, we would make it worse because we’d be putting an additional burden on our design team.
What this example is intended to demonstrate is the following: when you ask a team to build a thing without allowing them the time to validate that the thing will have the impact that you’re expecting it to, you’re opening yourself up to a lot of risk. In this example, we could have spent a lot of time and money building a tool that exacerbated our problem, rather than solving it.
Sometimes, there is a perception that this kind of activity slows down delivery. For one, I’m not sure that’s even true. I’ve worked in plenty of teams where user research has happened quickly. Second, if it is true, it seems a small price to pay. User research helps you to deliver products and services that will meet your user’s needs. If they do that, then they will create value for your organisation. That’s got to be better than risking spending time and money on something that won’t work.
And this all circles back round to the point about what agile means to different people and the importance of shared understanding. In my opinion, you can’t be agile without being user-centred. And being agile doesn’t just mean developing as fast as you can.
9. Agile sounds easy, but it’s actually really hard
On the surface, agile looks kind of easy. When you put it into plain language, people often say it sounds like common sense. However, if it really were that easy then you wouldn’t have people like me and my team helping organisations to do it. It’s worth highlighting that right now I’m specifically talking about big, complex organisations that existed before the internet did. This is where my experience has been. It’s also often these kinds of organisations that feel the need for and also the pain of digital transformation most acutely.
I think there are 3 key reasons why adopting agile ways of working in this kind of context is harder than it seems.
Agile forces you confront the fact that there is very little which we can be certain about.
That is very uncomfortable. It is also not usually what our organisations want from us. Our organisations want certainty about what we’re going to deliver, when we’ll have done it by and how much it’s going to cost. Unfortunately, these sorts of things are now much more difficult to predict. There’s an excellent book called Sense and Respond by Jeff Gothelf and Josh Seiden which talks about this phenomenon and how to handle it. They sum up the situation like this:
“[T]he digital revolution has brought to the world of business two critical forces. The first is uncertainty: as our software systems get more complex, it becomes harder to predict what people will do with them. Savvy companies are adapting their processes to deal with this by harnessing the second force: continuous change.”
Taking an agile approach is a way of embracing and managing the inevitability of change. But first, you have to accept it.
Agile requires people to behave differently to what they might be used to at work.
It’s not just organisations that want certainty, people want it too. After all, what is an organisation if not a collection of people? When you’re working in an agile way, you’ve got to get comfortable saying things like ‘I don’t know’, asking questions and getting things wrong. People feel and experience those things all the time, but admitting it and talking about it might not feel safe. A team need to get comfortable with that kind of behaviour to really benefit from taking an agile approach. It has to be legitimately okay to not know the answer and to get things wrong.
Agile ways of working need a particular set of conditions to a) survive and b) allow you to achieve the intended benefits of working in an agile way.
Adopting agile ways of working/practices/principles/frameworks at a team level is one thing. But to succeed, you need quite a bit more than that. This means that agile is often completely at the mercy of the way your organisation works, especially when you’re just getting started with it.
An agile team need certain things in their environment to be true to be able to genuinely get the benefits of working in an agile way. For example, they need things like:
- problems to solve, instead of fixed and highly defined deliverables
- the freedom to make decisions and respond to new information (for example about your users, your external environment and your organisation)
- an incentive to prioritise learning about user needs over delivery
Before I go on, I want to touch on that last bullet point. Learning about user needs and delivering tangible outputs aren’t mutually exclusive. And sometimes you do just need to build stuff. But the point is that you also need to be able to learn about your users and their needs. If that means delivering stuff more slowly, or not delivering what you expected to, that needs to be okay.
Often, teams aren’t operating in an environment where these kinds of things are in place. These are systematic, structural and cultural challenges that require systematic, structural and cultural change. And changing how things work is hard.
When you’re just getting started with agile, it’s extremely vulnerable to these kinds of problems. The organisational context many of us are operating in isn’t designed for agile ways of working. Another way of putting it is that our organisations haven’t accepted uncertainty as a given. That, in turn, makes it hard to prove the value of working in an agile way. It’s also why there’s a lot of talk about how difficult it is to scale agile ways of working. It’s because to scale agile ways of working, you have to fundamentally change how your organisation works. You can’t just adopt a framework.
Unfortunately, agile doesn’t have a clear-cut, straight-forward answer for that. That’s because it’s a set of principles and values. It’s also because every organisation is different. There is no one-size-fits-all approach. However, you can still learn a lot from stories from other organisations and other people’s experiences.
So if you’re trying to adopt an agile approach in your organisation and you’re finding it difficult, don’t be disheartened. It is hard! But do go and see how other people and places are doing it. Just copying them won’t work, but it might just help you figure out your next step to try.
10. The messy and often misunderstood relationship between agile and governance
A common narrative about agile ways of working is that they seem a bit careless, a bit unconsidered and perhaps even a bit naïve. We’re supposed to have a plan and we’re supposed to know what we’re doing. On the surface, agile sort of looks like it lets you off the hook for not having a plan and not knowing what you’re doing. That sounds like professional negligence, right?
First things first is that this narrative isn’t actually true. Agile is all about planning, it’s just that it also accepts uncertainty, so the plan looks a bit different.
Second, what people often don’t realise is that the principles and values of agile ARE a form of governance. Again, they just look quite a lot different to the kind of governance most of us are used to.
I’m going to try and illustrate my point by talking about just 3 of the principles and values from the Agile Manifesto. I’ll explain how embodying them in how you work will help you to manage risk. I’ll also refer to a couple of common practices that come from the agile frameworks.
Individuals and interactions over processes and tools
This is the first of the values in the Agile Manifesto. It’s about the importance of making sure your team are speaking to each other — openly and constantly. It also assumes that you’ve got the right skills working together in a cross-functional team from the start, which is another way you can massively de-risk your work. Finding ways of working aligned to this value helps manage risk because when you’ve got the right people working together and talking to each other, issues are way less likely to fester and grow.
One example of how you can adopt this principle is by having a daily stand up. In a regular stand up, your whole team gets early visibility of what’s happening and if there are any issues, which means you can act quickly and in a way that is aligned. This is a fast and light-touch way of managing risk.
Responding to change over following a plan
This is the fourth agile value. People often think that being agile means not planning ahead. What it really means is not planning beyond what you can reasonably know. In an agile way of working you plan, and replan, regularly. This makes it much easier to take on board and respond to new information, which hopefully you’re getting all the time as you work to understand your users, their needs and the opportunities for your organisation. It doesn’t mean never looking beyond the next 2 weeks. It’s just about being aware of what you do and don’t know now and not spending lots of time in the detail of a future which is so uncertain.
Allowing your team that flexibility is much less risky than making a big plan at the start and not having the opportunity to validate what you’re doing as you go along. It helps you to mitigate risk and manage your costs more effectively. If you’re set up to respond to change and understand your users’ needs, then you reduce the risk of spending your time and money on something that’s not going to work.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
This is the last of the agile principles. It’s all about giving a team the space to continuously adapt and evolve their ways of working for the better. A team that does this gets more effective over time. This is a powerful way of managing risks associated with ways of working issues.
One way in which teams often practice this principle is through retrospectives. This is where the team gets together to talk about their ways of working, acknowledge and protect what is working, and adjust what isn’t. Again, it’s somewhat less formal and prescriptive than the kind of governance we normally see, but it is a great way of empowering your people to take ownership for their own success.
These are just 3 ways in which adopting an agile way of working can support you not only to deliver but also to effectively govern your work. And this is just scratching the surface — there are many, many more examples. Adopting an agile way of working is a governance in action. So I hope I have gone some way in debunking the myth that agile doesn’t involve or care about effective governance. It’s not true and guess what? I hate it!
The end
And there we are, 5 more things I hate about agile, bringing me to a romcom-inspired total of 10.
Agile can be confusing because it means different things to different people. Done badly, it can provoke a decidedly un-agile us-and-them mentality. Sometimes it is misused and reduced to churning out outputs at the expense of user needs. Often, it sounds kind of easy when it’s actually very hard. And last but not least, it has a bit of a name for itself as a way of working that shuns governance and order, when really that’s what it’s all about.
With a bit of luck, you’ve found something in these 2 posts that resonated with you or gave you something new to think about. Or maybe it just helped you decide what film you’re going to watch this evening! If any of these problems are getting in the way of your team or organisation’s positive change and digital transformation, I hope my tenuously romcom-themed working out loud helps a bit. And to borrow Kat’s closing words in 10 Things I Hate About You:
“But mostly I hate the way I don’t hate you. Not even close, not even a little bit, not even at all.”
@convanzan
