Like RACIs, project plans have a lot to answer for. Most project plans are hard to read, hard to update, and almost immediately out of date. I’m pretty sceptical of any project documentation that requires lots of time spent up-front to only approximate the reality of what you are doing, and project plans are often an example of just that.

With agile, instead of spending a lot of time developing a detailed plan at the start of your project, you take a more iterative approach.

That doesn’t mean you do no planning. But it does recognise the limitations of planning.

Why planning is difficult

It’s helpful to start by recognising why planning is so hard. The biggy is that things change. We have imperfect knowledge to start with about how long something will take, even before you take this into account. But inevitably, what’s true at the start of your project won’t be true six months in.

Someone will leave your organisation, or the priorities will shift for a team you rely on. Things change externally too – tech, legislation, public opinion, the economy… It’s increasingly true that unpredictable global events will impact what you are working on. And the further ahead you try to predict, the more unpredictable things are, both internally and externally.

More than this, things should change. You should be learning things as your project progresses that change your approach. A project plan that doesn’t allow for this is unhelpful!

Deadlines are difficult too. We tend to use them to keep projects on track, but when things change, deadlines change too. This causes two problems. Firstly, setting and adjusting deadlines is very time consuming. It’s easy to spend a ridiculous amount of time repeatedly updating dates on a Gantt chart.

Secondly, deadlines do funny things to your brain. We use them as a signal of importance, but urgency is not the same as importance, and most deadlines are somewhat arbitrary anyway. This leads to lots of stress trying to meet deadlines that probably weren’t realistic in the first place. And this isn’t necessarily the same as doing the things that are most important for your project.

An agile approach helps address these challenges.

Things change, so your plans should too

When you work in a more iterative way, you stop trying to plan the future in detail. Instead of nailing down every step you are going to take, you start by working out what outcomes you want to achieve and then consider what you can do now to help you get there. Only once you’ve done that do you consider your next iteration. In other words, you plan in detail for the short term, but stay much more light touch for the long term. There might be some big milestones you need to meet along the way, but beyond noting those you don’t spend much time planning an unknowable future.

This only works if your plan is a live document. This means it needs to be easy to update (a Kanban board is much better for this than an Excel document), and you need to have a regular structure for reviewing it so that you are maintaining your planning for the short term. This is where I sing the praises of stand-ups again. Using a similar structure (perhaps less frequently) for project plans at a regular cadence allows you to plan as you go and keep things on track.

Avoid deadlines where you can

This one is counter-intuitive. But it made a huge difference when I stopped trying to add deadlines to everything. And holding on to deadlines is one of the biggest blockers I see to teams trying to adopt stand-ups.

If you are truly reviewing your plans at regular intervals, you shouldn’t need the deadlines just to make sure you do the work on time. Instead, each time you review your project plan, you should be prioritising what work you want to do before your next review. This gives you the opportunity to spot if something is truly time-sensitive and needs to be done now. But it also allows you to take other factors into account in your prioritisation, so ultimately you make better informed choices.

My formula for an agile project plan

Ok, that’s a lot of theory. But what does this look like in practice? You still need to do some work up front. It’s just not as detailed as in a non-agile approach.

1. Start by spending time working out what outcomes you want from the project. If you can do this collectively as a project group, even better – it helps give them buy-in and ownership for the final results.
2. Break the work down into areas (eg marketing, website development, internal comms). List any activities you are already aware of under each area (eg develop marketing assets, chose marketing channels etc).
3. Plot activities on to a high-level roadmap. For some projects, there will be natural phases you can split things into, but if not, keep it simple! A Kanban board with columns for ‘now’, ‘next’ and ‘later’ should do the trick. You should have just a few things in the ‘now’ column and lots more in ‘later’, to help you plan in detail for the short-term whilst keeping the long-term light touch.
4. Review your roadmap regularly. The frequency will depend on the type of project, but make sure you have a regular, predictable pattern to review. This probably needs to be at least once a month, and possibly as often as weekly. Each time you review, plan in detail for what you will do between now and the next review. If you think of something that needs to happen later on, capture it so it’s not floating round your head. But you won’t plan that in detail until you get to that point.

How do you approach project planning? Do you have a rhythm that works for you?

When we think about accountability, we default to thinking about managers. Managers keep people accountable by telling them what to do, and creating consequences if they don’t do those things.

But people aren’t dogs waiting to be biffed on the nose with a rolled up newspaper for peeing on the carpet. When someone fails to do something they were accountable for (or that their manager thought they were accountable for!), this is almost always down to a lack of clarity, skill or motivation. Clarity is the big one: they didn’t fully understand the task or their role in it, or they weren’t clear on how to prioritise it over other things. Lack of skill is straightforward: perhaps they just aren’t able to do what they’ve been asked to do.

Motivation is more subtle. It’s usually not that people lack any motivation to do their jobs and are continually looking for opportunities to goof off. But often we lack motivation for tasks that are ambiguous or where we don’t understand the purpose. Both of these come back to a lack of clarity again, and more importantly, to a lack of ownership.

Whatever the reason, relying solely on managers telling people what to do isn’t the solution for accountability. We often expect managers to give full clarity about responsibilities in a single conversation, but this is a big ask!

Managers don’t know everything. They don’t know what their report doesn’t know. And they often don’t know what their report does know, the things the report is aware of that will impact on the task. Managers shouldn’t try to be experts in everything their report does – that limits what the team can achieve to just the things the manager knows about in detail. It’s good for a team when different people develop different expertise!

Teams perform best when each person has clear ownership for their responsibilities, and can develop their expertise in those areas. Just telling people what to do isn’t going to achieve this.

What does work for accountability?

Clarity and ownership are the essential ingredients for accountability. And agile can help with both of these.

I talked a couple of weeks ago about how stand-ups can bring much greater clarity on responsibilities. Having quick, regular and structured conversations about what people are working on makes it clear what the expectations are and reveals blockers early. If someone doesn’t understand a task, or doesn’t have the skills to complete it, that should quickly become obvious in your stand-ups. And this shouldn’t be threatening – stand-ups are not a space for managers to catch their teams out. Instead, stand-ups should be a safe space for team members themselves to raise questions and concerns and get support if they need it.

One of the surprising shifts you make in stand-ups is that it stops being just the manager holding people accountable. Instead, the whole team is setting expectations about what’s needed, observing whether people have completed tasks they have committed to or not. And it goes both ways – the team gets to keep the manager accountable to their commitments too.

Stand-ups are my number one tool for creating clarity. But agile can help with ownership too. The shift I just mentioned is part of this, as it gives the whole team a clearer collective responsibility for their goals.

The other big shift is involving people in the decisions that affect their work. Being a more empowering manager gives people the opportunity to affect direction, which in turn gives them more ownership. This works even better if there’s space to create a shared vision for the work, perhaps using one of my favourite meeting formats to get input from the whole team about what you are trying to achieve.

The manager’s role in agile accountability

This might sound like the manager has no role in creating accountability in an agile approach, but that’s just not true. Instead the manager’s focus shifts to creating the structures that create shared accountability. Managers have an important role in modelling behaviour – for example, sharing when they are stuck and need help; or committing to work and sticking to those commitments. They can also use a coaching style to increase accountability, either by making observations (‘I notice we haven’t made any progress with this task for a while now’), or by asking questions (‘What’s realistic here?’, ‘What would you need to finish this by our next meeting?’).

Working in an agile way doesn’t abdicate responsibility for managers. It just helps them shift from a top-down model to a more shared approach to accountability. And ultimately, that’s more effective.

How do you create accountability? Have you found ways to do this collectively?

This is the first in a series looking at the agile approach to areas of our work we often don’t think about enough. Next week, project planning!

Last week, we discussed why the RACI model sucks. Planning out responsibilities in detail at the start of the project can prevent you from learning and adapting as you go. A much better approach to divvying up responsibilities is to have a regular, structured conversation about them.

That’s the “R” in RACI, but what about the other letters?

Most people find “consulted” the trickiest bit – involving everyone who needs to input into a decision, without a massive, unwieldy process. How can agile help with this?

Reduce how much input you need

Perhaps unexpectedly, I’m going to advocate for involving fewer people than you think in making decisions. This is despite what I say about the importance of empowering people through collective decision making. The critical distinction here is that decisions should be made by the people doing the work, rather than a long list of senior stakeholders or others who are peripherally involved.

If there are a dozen people you need to consult every time you make a minor decision, nothing will get done. But you can avoid this by spending more time upstream.

Invest time in collectively agreeing some bigger picture outcomes you want to achieve together. Then use these as the basis for your individual bits of work. Most people prefer to be consulted this way, as it allows them meaningful input without commenting on endless drafts. It also means you can move much more quickly once you’ve got started.

How do you do this in practice? It could be as simple as spending some time in a project kick-off meeting individually capturing what outcomes you would each like to see. Theme the answers and use these to set your overall goals for the work.

You can reduce other consultation needed further by giving people tools to help empower them to work independently. Perhaps you want everyone to draw on similar messaging, reference some key facts or use certain layouts in the design of their work. If so, give them a toolkit explaining all that.

Get feedback efficiently

Of course, there will still be times when you need to get feedback. How can you make the process as smooth as possible?

Perhaps you can get all the input you need in a single meeting discussing a concrete proposal, using the silent meeting format I’ve talked about before. Or maybe you just need to make a collective decision and some agile decision making tools might help you.

Where you do need to lots of people to comment on something, give then a clear and transparent process. This could be a live document where everyone can see other people’s comments, accompanied by some clear deadlines. Make it clear that if you don’t receive feedback by a certain date, you aren’t able to include it.

One person should own the process and resolve any competing feedback. Approach this with the mindset of being an informed captain – you are ultimately responsible for the decision, but you will take time to listen to input along the way. Netflix use this approach and says it allows them to be ‘highly aligned and loosely coupled’, which is a great way of putting it!

What about you – how do you manage who gets to input into decisions?

Working out who should be Responsible, Accountable, Consulted and Informed on a project should make roles much clearer, right?

Wrong.

Every time someone asks me for a RACI, my heart sinks. I have spent so much time agonising over so many RACIs that only a few people have even skim read. There must be dozens of massive spreadsheets I’ve written over the years to try and answer some basic questions about roles and responsibilities. Yet every time questions pop up, it seems unclear. A RACI might be a helpful starting point, but as soon as your project starts you will think of things you haven’t covered, or discover nuances in things you have covered.

If I’m honest, my RACIs have been expectation setting of the worst kind. It’s me saying ‘I’m not going to consult you about an important decision, and I’ll use this spreadsheet you won’t read to justify this to you in a few months time’. And that’s… not great?

I’m not saying that we shouldn’t set expectations, or that we should involve an unmanageable number of people in every tiny decision. But we use RACIs as the decision making equivalent of security theatre. It’s a bureaucratic piece of admin we spend a disproportionate amount of time on, given how little they help in day to day work.

What does help instead of RACIs?

The goal of RACIs is laudable. We want to be clearer about two things: firstly, who is responsible for tasks, and secondly, how decisions work – who gets to make or input on the decision and who is just informed. One spreadsheet can’t do all of this. But agile tools can be a significant help.

Let’s look at responsibilities first. Next week, we will dig into how to get input into decisions.

Use stand-ups to get clearer on responsibilities

The only way to get clearer on responsibilities is to have regular conversations about them. We’re rubbish at predicting the future and it’s next to impossible to outline all the tasks involved in a project at the outset. So don’t try to do that!

Taking an agile approach means planning in detail for the short term, and keeping it very top-line for the longer term. This is both much more realistic, and much simpler and easier to do.

One tool lots of teams I work with have found really helpful for this is a stand-up. Stand-ups are short, frequent meetings to streamline team communication and quickly address concerns. They take 10-15 minutes and are traditionally held daily, though I’ve found that weekly or twice-weekly can work well depending on the type of work.

For a stand-up to work well, you need a visual record of your work. You can use Microsoft Planner, Trello, monday.com or a similar alternative for this. The tool isn’t important, but how you use it is. All you need to do is make sure you’re capturing all the tasks for your piece of work under either “work in progress” for things you are working on now, “blocked” where you are waiting for something outside your control, and “to do” for anything you haven’t got to yet.

In a stand-up, each person should run through the tasks with their name on that are in progress. They should do this very quickly, just flagging if there’s anything unclear or where they might need some help. They should briefly check what’s blocked or still to do to work out whether they want to move anything to “in progress”, before passing to the next person.

This is a very simple format that you should be able to get through quickly. And there’s lots of benefits to holding stand-ups. They help you keep track of lots of moving pieces and they are an efficient way to make sure you are collaborating effectively. They also mean you are having regular conversations about workload so it’s easier to split this more evenly across the team.

But an underrated side effect of stand-ups is they quickly surface unclear responsibilities. You should spot immediately if there’s a task with no one assigned to it, or if someone is struggling with a task that’s bigger than they can handle. There’s no more mystery, no more hoping someone else will jump in. Having a regular, structured conversation means you will achieve clarity much more quickly.

That’s one way agile helps with clarifying responsibilities. Next week, we’ll look at the other important element of RACI and consider how you should involve people in your decision making.

In the meantime, I’d love to hear what you make of RACIs. Am I the only one who hates them? How do you approach clarifying responsibilities?

I think silence is an underrated agile skill.

That may sound odd, but fundamentally agile is a set of tools to help people collaborate and reflect. And you can’t do either of those things without silence.

Silence helps you pause, slow down and spot what’s happening. If all your meetings are non-stop talking, no one has a chance to think. It’s also harder for the quieter members of the group to speak up. Silence makes for much better meetings.

How silence feels to the facilitator

It might be incredibly valuable, but at first, silence in a meeting you are leading is so uncomfortable. Very often it induces mild panic. ‘Why is no one speaking? Argh, what do I do now?’ But once you get used to it, it can actually start to feel freeing. You know that thinking is happening, and if you just give it a moment, something unexpected will emerge.

Imagine gazing into a still pool of water. It might look like nothing is happening, but fish are swimming round below the surface. If you wait, one might emerge. But if you plunge your hand into the pool, you’ll never see them!

Thoughts are like fishes. Don’t scare them away by speaking too early.

How to tell if it’s a good silence

There’s two kinds of valuable silence in meetings. One is the silence of people working together individually. Maybe you’re getting them to note down thoughts on post-its separately, or you are using something like the silent meeting format we talked about last week.

If you can see people writing, the silence is working and you can leave them be. If you’re not sure, it’s a good idea to set a time limit for activities like this. It’s much more comfortable to be silent for a limited period, and no one will mind if it’s a minute or two longer than they actually think they need.

The other valuable silence is thinking time in response to questions in group discussion. This is harder to judge. How long should you wait before you should break the silence yourself with another comment or prompt?

It’s probably longer than you think. Silence feels much worse for the facilitator than for other participants, because you feel responsible for it. What seems like eons for you probably isn’t that long for the other people involved. And it can actually be a good thing if it starts to feel a little awkward – it gives an extra push for others to start talking.

So in general, hold your nerve and err on the side of more silence than you think. As long as you asked a good, open question that people could potentially answer, allow them the time they need to respond. Keep your questions simple and broad to make them easier to answer. ‘What stands out here?’ is my favourite for getting a conversation going after a bit of individual thinking.

How to get comfortable with silence

The best way to get comfortable with silence is to practice. Try holding a slightly longer pause in your next meeting and see what happens. Or watch what other experienced facilitators do, and notice what makes it easier for you to give good answers.

If you’re nervous about using silence, tell people! Explain at the beginning of the meeting that you’re trying to create more space for thinking and this might mean you go quiet after questions to allow people to process. Ask for feedback after your meeting to see how people found it. Chances are it will have been a lot easier on them than it felt for you.

Do you use silence in your meetings? How did you get used to doing that?

We’ve talked about empowering the team as part of working in an agile way, and how to make collective decisions as part of that. But what if you need to dig into a problem as a group before you make a decision? Here are three of my favourite tools to do just that.

Lean coffee

Lean coffee is a super simple, low-effort technique. It’s great when you have something you want to unpick but you don’t know where to start. It also works well as a way for attendees to build their own agenda in regular team meetings. And it requires very little prep!

All you need to do is introduce a topic and get people to tell you what they want to talk about. I usually give people three minutes to write down questions or ideas to discuss relating to your topic. Then we share and theme answers, before each using three votes to prioritise between them. We discuss the areas with the most votes, capturing notes and actions, continuing until we run out of time.

It’s easy, flexible, and makes sure you are actually talking about what people most care about.

Innovator’s compass

My next format is based on asking powerful questions. There’s more about how to do this here, but again it’s very simple. All you need to do is ask in turn about:

1. Observations: what’s happening and why?
2. Principles: what’s most important here?
3. Ideas: what could you try?
4. Experiments: what’s one thing you will do?

I suggest giving people 3-5 minutes to make notes on the first three areas individually, before sharing and discussing as a group. Then use dot voting to prioritise your ideas and flesh those out in the experiments stage.

Starting with observations and principles gets people thinking and leads to rich ideas for the third question. And ending with experiments helps you turn your ideas into practical actions.

Silent meetings

This works well when you want to discuss an existing idea in principle – perhaps someone has a proposal or a straw man that you want to get input on. The Silent Meeting Manifesto has lots of great tips for writing a good proposal for this.

Once you’ve got something concrete in writing, you meet to discuss, but you spend the first half of your meeting in silence. Everyone reads the document individually, adding comments and responding to others in writing. You only talk after everyone has finished reading and commenting, discussing any questions highlighted in comments that still need resolving.

I love this format. It’s much more efficient because everyone reading and writing at once is much faster than talking one by one. You end up having richer discussions, as the process of commenting means everyone has to really engage with the material so you start with a much clearer shared understanding of the issue. (No more endless recapping for people who didn’t do the pre-reading or who lost the thread during a boring presentation).

It’s also a good way to ensure more people participate, firstly because inputting in writing is more efficient, and secondly because lots of people find it easier to contribute that way than speaking up verbally in a potentially contentious discussion.

Those are three of my favourite group problem solving techniques. Do you have any others you would add?

Last week, we touched on the need for leaders to share power as a necessary criteria for working in an agile way. Flatter power dynamics have all sorts of benefits. Working in a less hierarchal way reduces the pressure on you as a manager. It uses the wisdom of the whole team, including those closest to the work who are likely to have the greatest understanding of the possible consequences of any decision. It’s great for getting your team to buy into the decisions and understand them on a practical level. And it’s good for your team’s development and critical thinking.

But how do you actually empower your team as a manager in practice?

Leaders go last

Who gets the most speaking time in your team? If power is well balanced, share of voice should be well balanced too.

For this to work you need to account for style differences. Whatever their preferences, level of introversion or neurodiversity, you need to make it easy for everyone in your team to contribute.

This means you need different ways they can give their input. If you always lean on group discussion and find you just hear from the same people, that’s a warning sign. Think about capturing written contributions, or asking people to chat in pairs before asking them to share idea. And don’t knock an icebreaker. Even for well established teams who know each other well, a good icebreaker can make it easier to contribute risky ideas later on in the conversation.

Remember that people tend to listen to you more when you are the manager, even when you’re not the best placed for an informed opinion. That’s why it’s a good idea to go last in a group discussion. Give everyone else a chance to share their views before you air yours. That way, you reduce the chance of influencing the conversation so that everybody agrees with you.

Sharing decision making

Hearing equally from the whole team is a great start. But it’s not enough if you still make all the decisions.

Practically, it’s much easier to make collective decisions than most people think it is. Spend time mapping out your options together, then use something like a dot vote to choose which one you want to go with as a team.

There’s lots more collaborative decision making tools in my guide to making better decisions with agile. But the important thing is to open your decisions up. Yes, there are some HR type decisions that only you as the manager can decide on. But if you start looking, there’s lots of scope to include the whole team in deciding what you’ll work on and how you’ll do it.

Go where your team tells you

If you make decisions as a team, you aren’t going to agree with all of them. And that’s ok. A helpful question to ask yourself is “is this safe to try?”. If trying something is hugely risky, that’s a good reason not to do it. But most things aren’t. And the benefits you get from empowering the team outweigh the downsides, especially if you are reflecting regularly together so can course-correct if something isn’t working out.

So if you hear your team telling you they want to go in a certain direction, listen to them. If someone gives you constructive feedback, visibly demonstrate that you are taking it on board. If someone wants to try something, work out what needs to be in place to make that safe to try.

What practices help you be an empowering manager?

You might already be “doing agile” – you just don’t know it yet

A common, but surprising reaction I hear when delivering agile training is that some of the content already feels familiar. Maybe one of their team draws on some agile practices even if they’ve never used the term. More likely, they emphasise with some of the mindsets I’ve shared and they can see them in their day-to-day work. Perhaps their role requires regular experimentation and they have a good rhythm of testing embedded in their work.

This is great and I encourage it. Agile is about mindsets, and if people can already start to see them in practice then they have a foundation to build on. People like being told what they are good at already! They will feel much warmer to agile and more open to trying new things if they can recognise ways in which they are already doing something similar.

It’s also helpful to acknowledge that agile is a spectrum, not a binary. You don’t have to do all the things to “count” as being agile. It’s much more approachable if you just start with one or two small things, and it’s even better if those strengthen things the team is already interested in or trying to put into practice.

Of course, there’s more to it

Agile practices reinforce each other. Labelling everything as agile feeds into some of the ways agile goes wrong, setting some fundamentally wrong expectations about what it actually is. But I think there are two complementary mindsets that are sufficient in themselves to enable genuine agile.

First, learning and adapting as you go.

This is often what people are getting at with experimentation. But doing a lot of A/B tests isn’t sufficient. You should be prepared to do things differently based on your tests, to work in short enough cycles that you can take what you have learnt from your experimentation and use that to change what you do in future. This means shifting from “oh what could we test next time?”, to really thinking through what your assumptions are and deciding what you’ll do if they are proved or disproved.

You also need to be learning from both your audience and from yourselves. A regular rhythm of reflection is fundamental to agile, which is why I’m forever recommending retros. If you really have an open, safe space to think about how you are working together and what you want to change, you will naturally get better. This takes time, but it’s like an investment with compound interest.

Of course, creating an open, safe space can be a big ask. And that’s why my other essential mindset is a willingness to share power. It has to be ok for each member of the team to speak up, share their opinions and disagree if they feel like it. And the more a team feel empowered to do that, to make decisions about things that affect them, the more you will be able to learn and improve and use the wisdom of the entire group.

There’s lots of ways for leaders to share power. Ask for feedback, make some decisions collectively, give people real ownership over the things they are closest to. Combined with regular reflection, it’s my MVP for approaching work in an agile way.

Can you see signs of agile mindsets in your team, even if you don’t formally follow agile?

Last time, we touched on two important mindsets needed for making the shift to agile: a willingness to let the team decide, and a willingness to experiment. But how do you live those out in practice?

Letting the team decide how to adopt agile

If you’re the leader, you may have some ideas about what you want out of agile. There’s probably some improvements you’d like to see, some changes you’d like to make to your ways of working. And that’s great… but only if your team sees it the same way.

The answer here is not to persuade your team to agree with you. The answer is to agree as a team what you want collectively, even if that isn’t exactly what you would have said yourself.
The way I do this is to start by introducing teams to the possibilities of agile, sharing a case study and some principles. Then I ask my magic question:

Imagine it’s a year from now, and we’ve made some really good changes to our ways of working. What outcomes would you see?

I let people capture answers individually, before gathering similar ideas together. Every time I do this, a set of clear themes comes out. Maybe the team wants to feel more connected, or have a clearer pipeline of longer term work, or more time for development.

It usually won’t be exactly what the manager would have said; there will be overlaps, but there will also be some nuance or new ideas that the manager will have missed. And that’s a good thing! The manager is just one person. Letting the team set outcomes collectively makes for better outcomes, because they will be informed by each person’s experience. It also means they will be more bought into making it happen.

Once we’ve got some clear outcomes to aim for, it’s much easier to think about what agile tools could help. I’ll suggest a few things and get the team to vote on the options.
This gives you a great start, but you still need another piece of the puzzle: experimentation.

Experimenting your way into agile ways of working

It’s inevitable, in your shift to agile you are going to try some things that don’t work. But as long as you are trying things – and stopping to reflect on their impact – that’s not a problem.
That’s why I always recommend that teams trialling agile try retros, whatever other practices they are adopting.

Retros, or regular shared reflections on how you are working together, are valuable for all sorts of reasons. But if you are changing how you work together they are even more important, because they give you a natural point to pause and think about how it’s going.

Often you’ll realise things like you’ve scheduled something badly, or you’re not prioritising frequently enough, or you’re not distributing work evenly between the team. That’s all good learnings! A retro provides a safe space to recognise these things and decide how you’re going to respond. It means you are set up well to improve how you work over time.

How did you get started with agile? Or if it’s something you are considering, how will you involve the whole team in choosing and experimenting over what you try?

Agile doesn’t work for everyone. Often when I mention agile to others, they groan, because they’ve seen it done badly. I’ve seen two key failures that cause this: imposing processes on a team and not really trying agile at all.

Failure 1: agile imposed on a team

This is the failure I most often hear about in tech circles. A new leader comes in with the bright idea of adopting agile – maybe they’ve had good experience at a previous organisation – and they make the team work in this way by giving them a mandatory set of processes to follow.

This is head-to-desk-thumpingly stupid. It’s not what agile is about!

Agile is about mindsets – individuals and interactions over processes and tools as the Agile Manifesto puts it. It’s about how you think about things: being outcomes focused, having an experimental mindset, distributing power rather than making all your decisions top down… The tools are only useful to the extent that they support those ways of thinking.

Imposing the tools on a team overrides the context, needs and interests of the people in the team. It’s doing the exact opposite of what you’re supposed to do in agile, which is giving the team the power to choose how they work. So it becomes an annoying new bunch of admin and further evidence that leaders aren’t really listening to their teams. The Manifesto for Half-Arsed Software Development captures this well – doing it this way is doomed to failure.

Embarrassingly, I’ve been involved in this in the charity sector too. I was excited to be bought in by some senior leaders to support a team who were struggling to prioritise a strategic piece of work. But it turned out the team had no opportunity for input.

They were given a list of tasks without any say in the details, and unsurprisingly, the details were wrong. It was all well intentioned, but the people setting direction weren’t close enough to know what was realistic or likely to succeed. And the team knew it. Having this list imposed on them was frustrating and disempowering, and naturally they didn’t care all that much about the outcomes. All the processes in the world for better prioritisation can’t help when what you are prioritising is just misguided. It doesn’t work unless you give the team more say.

Failure 2: Not really trying agile at all

I’ve seen an astonishing number of things labelled as agile. Working faster. Changing your mind a lot. Hot desking (really!). Often it’s an excuse to give a team more work without extra resource.

Yes, agile can help you do things more efficiently. In theory you can do more work, or at least, more impactful work, because you’ve stopped doing things that aren’t as good a use of your time. But again, this only works if teams adopt the mindsets of agile, if they are empowered to ruthlessly prioritise, if they spend time experimenting and learning so they can improve. And this doesn’t happen if it’s just some buzzwords rather than a shift in thinking.

The most insidious version of this is subtle. A team might have bought into trying agile themselves, using a lot of the language and regularly holding agile ceremonies. But you dig into it and it’s tokenistic. They hold what they call stand-ups – once a fortnight and it takes an hour. They’ve added this on top of other meetings. It’s all a bit frustrating and sad. Again, they are focusing on processes and tools over ways of thinking.

What’s needed to make the shift to agile successfully?

As we’ve seen, tools are not enough to successfully shift to agile ways of working. You need engagement from the whole team. More than that, you need to give power to the whole team. Leaders can set vision and direction, but they need to trust that their team are best placed to work out the details. They need to be given the space to work out how they’ll get to the vision, and that includes deciding how (or if!) they will adopt agile.

There also needs to be an openness to experimentation. You won’t get agile perfect to start with – in fact, there is no such thing as perfect ways of working. But you will learn a lot over your first few months, and you have to be willing to try things and adapt as you go. More on this in my next blog.

I want to emphasise that agile is worth it! I’d argue that what I’ve described here isn’t really agile, even if that’s what people are calling it. Done properly, agile reduces risk and uses the wisdom of the whole team, in a way that enables you to be much more effective. Done poorly… well, it’s just a bit frustrating.

Have you seen agile fail? What’s you reaction when you hear it mentioned?