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?