This is good for the coachee, because stretching your thinking is how you develop skills. And it’s good for the whole team, as the ideas that emerge in coaching tend to be more considered.

If you’ve not experienced coaching before, it’s worth saying a few words about what it’s like. Coaching is a structured conversation where the coach asks questions to help unlock the other person’s thinking. The coach isn’t there to provide advice or give answers (however much we may want that sometimes!). Instead, they will gently probe about what the coachee’s goals and options are, helping them to slow down and look at a problem in another way.

Outside of formal sessions, a coaching approach can also be used in our day-to-day work. For example, if someone comes to their line manager asking what to do about the situation, instead of giving an immediate answer, the manager might ask some questions. What do you want out of the situation? What do you think other people might want? What are some different ways you could approach this? Usually, some unexpected insights will emerge.

But the manager doesn’t have to be the coach. I personally regularly get coached by people I manage, and we hold regular peer coaching sessions. It’s one of our most useful tools to unlock problems.

Agile mindsets in coaching

Coaching relies on the idea that the people who know most about a problem are the ones closest to it. This is a core idea in agile. Instead of defaulting to asking someone more senior, or doing what you’ve always done, agile helps create structures so that everyone can use their own expertise and make their own decisions.

This is honestly a bit of a relief as a manager. There’s plenty of things my team knows way more about, and I don’t have enough space in my head for all of their work context as well as my own. Empowering them to independently solve their own problems feels better for both them and me.

People are also much more bought into ideas that they’ve come up with themselves. You can see this emphasis on ownership in agile practices like backlog refinement and stand-ups. Empowered teams care personally about what they are doing and are more effective in doing it.

Reflection is another core agile mindset. It’s very difficult to learn and adapt your approach if you don’t have the space to stop and think about it. I find I reflect much more deeply with coaching, as it deliberately slows you down to explore something more thoroughly. It reminds me of Oliver Burkeman’s advice to develop a taste for problems. Coaching is one way I move through the discomfort of not knowing the answer, to really think about possible ways forward.

Coaching and psychological safety

Coaching relies on a certain amount of psychological safety. But done well, it should also help foster that safety.

If people don’t feel basically safe with each other, coaching won’t work. People need to feel comfortable sharing what they don’t know, or where they are stuck. Being coached is inherently vulnerable and, like agile, relies on a base level of psychological safety.

But if you have that safe foundation, coaching is a practice that can help reinforce psychological safety. We can’t just tell people that they should feel safe sharing – we need to demonstrate it. Coaching means really listening to someone without judgement. It’s a clear signal that their thoughts and opinions matter, that you believe they have the resources within them to solve their own problems.

Our default ways of interacting often set the expectation that managers have all the answers – which implies that non-managers’ ideas are less valuable. By helping you shift away from this, coaching makes it easier for the whole team to speak up. When no one person has all the answers, it’s easier to share your own perspectives even if these differ from the group.

Next week we’ll look at how to get started with coaching. Sign up to my newsletter to get a regular round-up of posts.

How we think about time matters

Until I read this book, I was only vaguely aware that you could have a different attitude to time than our cultural norm. But of course how we currently think about time is a fairly recent phenomenon.

As Burkeman points out, medieval peasants didn’t just lack our worries about work-life balance, they wouldn’t have experienced time as the abstract entity that we see it as. If you get up when the sun rises and go to bed at dusk, and your life is driven by the seasons and when the cows need milking, your attitude will be very different to one driven by the clock. You can’t get ahead on milking the cows or harvest the crops at a time that is convenient to you. These things happen when they happen.

And despite the hardships of peasant life, they didn’t feel stuck with too much to do like we do. Our technological advances and labour saving devices have not made time feel more abundant. Somehow, it’s the reverse. Getting more done often leaves us feeling busier and more anxious and somehow empty as a result.

Too many of us live with a ‘when-I-finally’ mindset, stuck in the idea that ‘when I finally get this big project done/ hire a full team/ move house/ meet the right person… then I can relax and start living the life I was always meant to be living’. But there’s always something else you want to achieve when you get there.

When you recognise that you can’t do everything, you stop trying to do everything. You stop feeling like if you just clear the decks you will finally get on top of things. You will never clear the decks.

The book doesn’t advocate that we think like peasants, but it does illustrate that we can think about time differently from the cultural default. Because, as Burkeman describes, ‘this attitude towards time sets up a a rigged game in which it’s impossible ever to feel as though you’re doing well enough. Instead of simply living our lives as they unfold in time – instead of just being time, you might say – it becomes difficult not to value each moment primarily according to its usefulness for some future goal, or for some future oasis of relaxation you hope to reach once your tasks are finally “out of the way”.’

Choosing what not to do

One of the most important implications of the fact that time is finite is that good time management techniques doesn’t just help you get more done, but helps you neglect the right things. In agile, we’d call this ‘maximising the work not done’.

I remember the first time this was explained to me. I was working on an improved process for volunteer groups to order fundraising materials and I knew they would find it much more convenient if those materials could be batched to make it easier to divide amongst themselves. I was trying to work out the logistics of making this happen, and I was very proud that we’d come up with the idea. But when someone asked what would be different as a result of this change, I realised the answer was… nothing. The groups were ordering the materials, whether or not I made this complex and logistically challenging change. This was work I could easily not do without impacting my results.

I’ve written about backlog refinement as a practice that helps you prioritise a few things to focus on. Implicit in choosing what to do is choosing what not to do, and that’s almost more important. As the book points out, spending several of your four thousand weeks on something inherently means choosing not to spend it on something else, whether you recognise it or not.

One thing at a time

One of Burkeman’s recommendations is to serialise what you focus on. Pick one big project to focus on now, and wait till you finish to choose the next one. This is probably a familiar idea from agile, and it’s amazing how much more you can achieve if you are really only focused on one thing for a while.

Burkeman also cites Hofstader’s Law, that things take longer than you expect, even when you take Hofstader’s law into account. He gives it an unexpected corollary that perhaps we should resist the urge to pad our timelines, because things will inevitably take longer when we allow more time for them. This is another reason why design sprints, week-long workshops focused on exploring one problem in depth, work so well. A sprint is always structured to involve testing with your target audience on the final day. That in-built timeline means there can be no slippage into the following week.

Develop a taste for having problems

The final idea that Burkeman shares that has really stuck with me is about considering patience as a creative force. We want quick answers to our problems, but interesting problems don’t have quick solutions. You often have to stay with a question and endure the discomfort of not knowing for an answer to emerge.

I think so often we use productivity as a way to distract ourselves from these difficult questions. It’s easy to abandon a tricky project if you’ve got 16 other things you’re supposedly focussing on. But often there’s gold on the other side of the difficulty. If you push through the discomfort, valuable insights emerge. That’s why a lot of facilitation and coaching is really just about slowing people down – encouraging them to stare a difficult problem in the face for a bit longer than they would in their day-to-day.

The wider insight is to not be afraid of difficulty, to welcome even incremental change on problems that matter. Burkeman calls this developing a taste for having problems, and I love that framing. I also love the question he asks towards the end: ‘Where in your work are you currently pursing comfort, when what’s called for is a little discomfort?’.

Where should you be pursuing more discomfort? Share your reflections in the comments and sign up to my newsletter for monthly agile advice and tips.

Why email sucks

The book argues that we unquestionably assume email transformed work for good. ‘According to this premise,’ it says, ‘if you feel overwhelmed by tools like email or instant messenger, it’s because your personal habits are sloppy: you need to batch your inbox checks and turn off your notifications, and write clearer subject lines!’. But email and similar tools have changed the very nature of how we work, often in troubling ways.

The assumption that we should always be available and interruptible (what Newport calls the hyperactive hive mind) is ubiquitous in knowledge work. But we work better and are more productive when we can focus properly. We all know the harm of multi-tasking, but we fail to appreciate the ways email and other forms of electronic communication encourage it. If you are in and out of your email inbox all of the time it becomes next to impossible to pay attention to your main task.

Research shows that there’s a cognitive cost to switching your focus from one task to another. It might just be a quick email check, but the attention residue that lingers for a long time after you’ve closed your inbox. This doesn’t just harm our productivity, it makes us miserable! That horrible foggy feeling when your mind has been pulled in too many directions is the result of this kind of task switching.

Kanban can help reduce email

Like several of the sneakily agile books I’ve reviewed, A World Without Email advocates using a Kanban board with a regular review meeting (or what I would call a stand-up). I’ve sung the praises of stand-ups before, especially the impact they can have on accountability, but Newport is right to highlight how they can reduce email too. 

Newport says that ‘a regular rhythm of efficient meetings can replace 90 per cent of hive mind messaging, if you have a way to keep track of what needs to be discussed in these meetings’. I’ve often found that teams that hold stand-ups rely less on email and IM as he describes. It’s often quicker to address a question in a quick chat in your stand-up than to write a lengthy email. And fewer questions even emerge if you are having regular conversations about your immediate priorities.

The book has several helpful builds to strengthen this. He encourages you to shift as much as possible of your written back-and-forth to your Kanban board rather than your email, adding comments, questions and related documents to the task cards themselves. This means your conversations are much more structured around the task, with all the relevant information ready to hand. It also makes async conversation feel more natural. You can review all of the comments relating to a particular task when you are focused on that specific task, rather than getting pulled out of something else all the time.

And if you don’t already have a ‘waiting to hear back’ column (what I’ve previously called a blocked column), add one! It makes it so much easier to remember when you are waiting for someone else’s input, without adding to your mental load.

He uses the example of IT ticketing systems as an adjacent practice. Ticketing systems like these have consistently been shown to reduce IT staffing costs, as focused technicians solve problems faster. It’s also better for the people requesting IT support, as they know what the status of their request is without asking.

Along similar lines, I often recommend making your Kanban board public if you can, particularly if you are a service team. Firstly, it will stop you from having to respond to lots of questions about progress if people can find that information itself. Secondly, it makes it easier for requesters to appreciate the relative priority of their request (and why you might not be able to respond to it instantly), if they can see what else you have on your plate.

How to focus on what’s important

Focus has been the other clear theme across this series. At a high level, this means determining clear priorities, perhaps using practices like backlog refinement or choosing a wildly important goal. What this book gets across is the benefit of more granular level of focus, applying your attention in the moment to just one thing.

For example, office hours are a great practice if you want to batch lots of quick chats in order to protect other time for more focused work.  I also loved the advice on minimising back-and-forth when scheduling meetings by using a service like Doodle, and by deliberately putting more detail into your initial message to reduce the overall load.

The overall concept of working on one objective at a time, without interruption, is a very agile idea. I often find people are astonished by the power of this when we hold design sprints, focusing on one idea across a whole week. This not only helps you feel productive, but it’s better for your mind as well.

If work often leaves you feeling tired, it might be worth reviewing how clear your focus is. I really recommend A World Without Email (and other books by Cal Newport like Deep Work) to help you think about this.

If you’re interested in learning more about agile, sign up to my newsletter for a monthly round-up of posts along with a tip and a question to help you take your practice further.

What I learnt about executing on strategy

The book argues that whilst we focus our time and thinking on strategy development, executing on strategy is a far bigger challenge for most of us. Executing is fraught with difficulty: unclear understanding of the goal, especially at lower levels within the organisation; murky accountability; problems translating plans into action.

There’s also the pull of business as usual – or as they call it, the whirlwind. I love the way this captures the irresistible pull of our day-to-day work. Even when you have clear and compelling goals, it’s hard to focus on those in the whirlwind of deadlines and daily expectations.

The book sets out a process that starts with setting just one or two wildly important goals. You then pick a small handful of lead measures that are influenceable and predictive of those goals and monitor these with a scorecard. Each week, you meet briefly to review the scorecard and commit to actions that will help you make progress on the lead measures.

If those brief meetings sound familiar, yes, there’s a lot of overlap with stand-ups – and I’ll come on to some of the takeaways I’ve used to improve my own stand-ups. But some of the concepts about strategy as a whole have been even more valuable to me.

Firstly, the idea that you should only have one (or at most two) core goals – as they call them, wildly important goals or WIGs. That’s not to say you can’t have other goals. But the more you try to do the less you will accomplish. The clarity of a strict one or two goal limit makes it much easier to make progress. This emphasis on focus is a very agile idea that resonates with what I’ve written before on backlog refinement.

To help you identify your WIGs, they encourage you to ask, ‘if every other area of our operation remained at its current level of performance, what is the one are where change would have the biggest impact?’. This is such a freeing question. So often we get stuck in setting goals around things that are already working. Of course we want to maintain our success in x, y and z, but often that will happen without much effort. Focusing on improving one thing is less overwhelming than asking what the most important thing is overall.

Reassuringly, they say that 80% of your team’s effort will probably be spent on the whirlwind, rather than your WIG. This seems realistic and helpful to acknowledge. Focus on a few things, do those well, and accept that whatever your intentions, your day-to-day job will automatically take up the bulk of your time.

They also encourage wide involvement in setting your WIGs, another very agile idea. As they put it, senior leaders should be able to veto, but not dictate direction.

Creating accountability

I mentioned that the weekly WIG meetings described in the book are very similar to stand-ups. These last 20-30 minutes (so a little longer than a typical stand-up) and are a chance to hold each other accountable. Each member of the team reports on their progress on the commitments they made last week, reviews their scorecard and makes new commitments for the following week.

There are a few bits of this that go against what I would recommend. There’s a real benefit to stand-up’s brevity: limiting them to 10-15 minutes makes it much more likely that you will stick to it and not get bogged down in conversation that’s not relevant to everyone. I’ve also never quite managed to get a satisfying scorecard going. I love the idea (and would love to hear if you’ve made it work for you), but distilling work into a small handful of lead measures always seems very tricky in practice.

Having said that, I absolutely agree that using a structured, focused format can help everyone keep themselves accountable. It’s also really motivating to acknowledge progress on a regular basis, whether that’s in the scorecard they advocate for, or in simply ticking things off in a more typical stand-up.

Empowering the team to keep each other accountable, rather than this solely coming from the manager is also really powerful. I also like the way each team member picks their own commitments each week. They know most about what’s possible to achieve, and if they chose themselves, they really are committing to it. Again, the framing is helpful: ‘what’s the 1-2 most important things I can do this week to make progress on our WIG?’.

I tend to use stand-ups in one of two ways. Either it’s for teams to organise all of their work together, or, in keeping with the book, it’s focused on a key project or goal that’s separate from the whirlwind. There’s value in either approach, but often the latter is an easier way in for teams that are newer to agile.

I’ve never followed the full process outlined in the book, but several of it’s ideas have strengthened my agile practice. I’d love to hear from you – does any of this resonate with you?

This is the third in a series sharing agile lessons from books that don’t describe themselves as being about agile. Subscribe to my newsletter to get a monthly round up of posts, and my free guide, How to Make Better Decisions with Agile.

This rhythm of working in short cycles, alternating between the two modes, also feels very agile. But the emphasis on language in the book is a subtle nuance often missed when thinking about agile ways of working.

How Leadership is Language relates to agile

Red and blue work need different approaches. Thinking mode benefits from embracing variability, getting diverse ideas and perspectives to improve decision making. Doing, on the other hand, benefits from reducing variability – focusing on consistency and execution.

This idea might sound familiar if you’ve read what I’ve written on convergent and divergent thinking. Again, these are two different processes, and we need to separate them out within our meetings.

Marquet is applying a similar concept to our work as a whole. We should look at as many ideas as possible in brainstorming, and at lots of different perspectives before decisions making. But in day-to-day execution, you should just focus on one thing at a time to avoid being pulled in too many directions. The trick is to get the right balance between the two modes, working in short cycles of doing interspersed with thinking.

This absolutely resonates with many agile practices. Agile encourages you to work in short cycles, pausing at regular intervals to reflect and improve. We don’t describe them this way, but retrospectives and idea generation should both be drawing on the blue thinking mode, introducing variability to help you improve. Marquet calls this ‘improve, don’t prove’. It’s all about a non-judgemental reflection on how things are going and what you might want to do differently.

Stand-ups are all about reducing variability, efficiently clarifying what you are focusing on that day. You should be breaking the work down into small, manageable tasks and completing them one-by-one. This is exactly what Marquet argues for as his ‘complete, don’t continue’ play.

But my favourite secretly-agile part of the book is the section on ‘collaborate, don’t coerce’. Marquez encourages leaders to empower their teams, listening to them and encouraging the sharing of ideas. Where possible, he wants you to let the doers be the deciders. Again, this is a very agile idea.

How the book can help you take agile ideas further

Unsurprisingly given the title of the book, some of it’s best ideas are about language. And it’s particularly helpful on ways leaders can use language to create true collaboration without subtly prompting the group just to agree with them.

This is how the book puts it:

‘When leaders attempt to collaborate with their teams, they often end up skipping the divergent part (“What does everyone think?”) and jump straight into the convergent part (“Here’s what I think. Does everyone agree?”). This represents the language of too many brain-storming and decision making meetings, where the boss states an opinion and others fall in line. Bosses try to be compelling, not curious. They ask leading and self-affirming questions. They suppress dissent and push for consensus. This is not collaboration. This is coercion disguised as collaboration.’

The book is filled with great ideas for how to tackle this. A few of my favourites:

1. Vote first, then discuss. I’ve written a lot about anonymous dot voting as a way to get input from a group rather than just the loudest or most senior person. The book takes this further by suggesting you vote before you discuss, so you aren’t influenced by what the leader thinks.
2. Asking probabilistic questions rather than binary ones. For example, asking ‘how likely is this to work?’ rather than ‘will it work?’ to allow more space for varying opinions.
3. Highlighting dissenting opinions in a non-threatening way. If you’re responding to a comment that’s an outlier from the group (perhaps added privately in a retrospective), asking questions like ‘What might be behind this?’, ‘What might someone who said this see that we don’t?’ invites the group to explore it, without automatically assuming it’s wrong.
4. Leaders speaking last in discussion, something I’ve also advocated for in my blog on how to be an empowering manager.
5. Asking good questions, without an implicit answer embedded in them. For example, ‘what are we missing?’, ‘what do you see?’ rather than, ‘is this right?’, or ‘have you thought about the needs of the client?’.

This is a book I keep coming back to. You probably can’t implement all the suggestions in one go, because remembering to change your language in the moment is harder than introducing a new practice like a retrospective. But just taking one or two ideas from it each time can make a big difference to how you are as a leader.

Have you read Leadership is Language? Did the resonances with agile strike you?

This is part of a series of reviews of books that are tangentially about agile. Subscribe to receive my monthly newsletter and not miss a post.

What David Allen says about agile

Team has a whole chapter on types of new work like agile or Lean. It describes them as a response to classic organisational dysfunctions like hierarchical structures, silos, slow decision making and rigid planning. That’s right on the money.

It also distinguishes between Agile (a rigorous, prescriptive framework) and agile (a less formal way of working in a way that enables small iterative enhancements). Each can have value but Agile requires substantial changes to organisational structure.

It’s a helpful distinction, but I think the line is blurrier than they are making out. I would also emphasise the mindsets behind agile more than the book does. It’s no good rigorously implementing an Agile methodology if you still have a hierarchical approach to decision making, or default to planning longer term than is realistic. Agile techniques should in theory help you make those shifts – but if you are rigidly imposing them on teams that aren’t interested, that’s a warning sign in itself about hierarchy. Teams should be adapting Agile (or agile) to suit themselves, reflecting regularly on what they would like to change.

Two of the book’s insights that I really appreciated: Agile (capital A), works best for groups who don’t have great workflow themselves. If you are starting from a low base, you’ll notice the most difference from implementing a more robust system!

It also notes that sometimes we resist moving to less hierarchical systems because we actually like the protection inherent in the old ways. As much as you might complain about having to get sign-off from six different people to make every decision, it does at least remove the risk of you being blamed if it goes wrong. That’s why I’d come back to mindsets again. If a team or organisation has really poor psychological safety, agile isn’t going to work for them.

Beyond the specific discussion of new work, there are several ideas about capturing, planning and prioritisation that Allen has written about that have really stuck with me over the years. For the most part, these came from Getting Things Done and so focus on individual time management. But they are easily extendable to groups, and I think having already internalised them made lots of agile concepts more immediately obvious to me.

Your mind is for having ideas, not holding them

A core insight of the Getting Things Done (GTD) system is that you should be rigorously capturing ideas and tasks in writing as they occur to you. Not only does this prevent you from forgetting them, it frees up your mind for other things. No more trying to work on a big project with nagging thoughts in the background about your shopping list and that email you really ought to reply to.

This seems almost embarrassingly obvious when you look at it, but for lots of people (me included!), this has had a transformative impact. It’s also one of the easiest ideas from GTD to adopt, even if you ignore the rest of the advice.

The corresponding agile idea is to capture your collective work in writing. I’ve talked about Kanban boards in the context of stand-ups before as a way to do this, but whether or not you hold stand-ups, this is helpful, easily actionable advice. And having a shared record of what you are doing together brings a lot of clarity. Listing tasks and responsibilities in writing removes a lot of ambiguity. It makes it much easier to avoid duplication, or lots of back and forth as you try and work out who to talk to about a particular project.

Planning, but not over-planning

One of my favourite bits in Team is the discussion of the annual planning cycle. It says, ‘So much effort goes into planning that in the end there’s a sense of, “Well, we’ve spent all this time planing it, so this is how it’s going to be, dammit!”… It is a form of magical thinking. Unfortunately, just because it’s been planned down to three decimal points in a spreadsheet won’t make it happen.’

The book goes on to say that whilst over-planning is a fool’s errand, not planning also doesn’t work either. Instead, they advocate having a clear purpose and vision, balancing that structure with more nimble responses to what’s happening around you. This is in many ways very similar to what I’ve written before about taking a more iterative approach to planning and strategy: starting with the outcomes you want to achieve and working out how you are going to achieve them as you go.

At a much more granular level, I love the GTD concept of next action. Instead of capturing everything you might need to do on a project, work out what you need to do next to move it forward and add that to your list. I think about this regularly in stand-ups. We don’t need to capture what we should be doing a month from now on our Kanban board. But we do need to capture what we should be doing now! Keep project planning light weight and review it regularly.

Prioritisation can be intuitive

The third area I draw on regularly from David Allen’s work is prioritisation. Firstly, that it’s important! Hopefully this is obvious by now, but having clear priorities for what to focus on is hugely valuable – and that’s a very agile idea.

Secondly, GTD advocates prioritising using your intuition, and whilst that initially might not feel like enough, it’s much more powerful than you think. If you have a regular, rigorous review of what you are committed to, you should be able to decide in the moment what to focus on. Frankly, half the battle is just making the decision. Choose one task, complete it, and then think about the next one – rather than spending half an hour fretting over what you should be doing, or flitting from one task to the next.

I also think collectively prioritising at a team level is easier than we make it out to be. Agile emphasises people closest to the work making decisions together, but people often resist this because it sounds difficult. Surely it’s much more straightforward for the manager to decide for the group?

But group prioritisation doesn’t need days of agonising over a complicated scoring system. My guide Using Agile to Make Better Decisions gives you lots of options, but at it’s heart decision making can be much more intuitive than you think. For example, in backlog refinement, just asking the team what’s most impactful to focus on now almost always elicits a clear answer. Occasionally you need to debate something for a couple of minutes, but almost always you’ll find ranking your priorities is very straightforward. You just need to spend a little time together to work it out.

Over the next month, I will be exploring other books that have influenced my thinking about agile (without strictly being about agile!). Sign up to my newsletter to get a regular round-up of posts with tips and questions to help you become more agile.

The trick with prioritising is not actually prioritising. It’s deprioritising. We’re very good at choosing things we want to do, but understandably much less good at picking what we won’t do.

Two pieces of advice make prioritising (and de-prioritising) work much easier: do it regularly and do it together.

If you are prioritising on a regular basis – say monthly – then it is much easier to choose what to focus on. If you don’t pick a particular task this month you can always go back to it next month. You have a regular opportunity to course correct if things go wrong or you learn something new.

Prioritising together leads to better decisions. How many times has a manager chosen something, only to learn that actually it’s not realistic, or overlooks a key dependency? I know I’ve done this frequently! Prioritising together as a team means that not only are you using everyone’s knowledge and expertise, but that you will all be bought in to your choices. It’s also a big shift towards being a more empowering manager.

Thankfully, there is an established process that gets you to do this collective prioritisation of work together. It’s called backlog refinement.

Backlog refinement, step-by-step

Before you get started, you need to build a backlog. This is a list of all the tasks you might like to do. Scour your current to do lists, any questions that have been nagging at you, things you’ve talked about doing someday, opportunities you might wan to explore and so on, and put these all in one long list. You’re not committing to doing something if you put it on your backlog, but you will consider it when it’s time to prioritise.

Then your regular backlog refinement session should go something like this.

1. Check in (5 minutes): Each participant answers a warm-up question in turn.
2. Review your priorities from last time (10 minutes): Ask people to individually tick off what you said you would do last time. Briefly discuss things that haven’t been completed.
3. Retrospective (20 minutes): Give participants four minutes to answer each of the following questions in turn:
   
   What’s gone well over the last month?
   What’s gone less well?
   
   Group together any themes and spend a few minutes discussing these as a group, before moving on to what you might like to try differently next month. Take notes of any actions that come out.
4. Choose next month’s priorities (15 minutes): Your goal here is to choose 3-5 priorities from your backlog to prioritise for the next month.
   • Ask people to individually shortlist possible priorities first, by silently grouping those post-its together.
   • Take two of the shortlisted priorities and ask which of them would be more impactful to focus on for the next month. Get people to shout out answers! Start ordering the priorities with the most impactful one at the top. Add in one priority at a time and compare it to priorities already discussed till you have ordered your shortlist.
   • Decide the cut-off point – how much of your list is realistic to do in the next month? Be ruthless – if you don’t think you can do it, it’s not a priority.
5. Break the task down (10 minutes): Ask participants to individually list out tasks and responsibilities for the priorities that are above your cut-off. If you are using stand-ups, one of you should transfer the tasks across to your Kanban board after the meeting.

What if something never gets prioritised?

If something never gets prioritised, then it genuinely isn’t a priority. And that’s ok! We can’t do everything. As long as you are regularly creating space to genuinely reflect and consider what would be most impactful to put your time into, if something doesn’t make the list then it doesn’t make the list.

Let’s face it, you probably weren’t doing those things under your old system. And if you were, what were you not doing instead? It’s much better to be honest with yourselves about the choices you are making.

What if we keep getting additional priorities imposed on us?

It’s next to impossible to prioritise if a week from now you’ll be told to focus on something else, and that’s true whether or not you are using backlog refinement.

If this is an issue for you, make sure you’ve communicated clearly about when and how you prioritise and set expectations what’s realistic for you to take on at any one time. It’s easier for others to accept that x isn’t the focus right now if they understand you are currently working on more important tasks y and z, but you’ll take another look at x on the first Monday of the month, say.

If additional prioritises are coming from more senior stakeholders, it’s worth spending time getting really aligned about the outcomes you want to achieve. Once they are bought into your overall goals it’s easier for them to leave it to you to decide how to achieve those. It can also be helpful to get them to shadow one of your backlog refinement sessions so they understand how you are making choices and advocate for your priorities amongst their peers.

You get better at prioritising over time

I’ve noticed several patterns with teams who use backlog refinement regularly.

After a couple of months, almost every group realises that they are prioritising too many things and adjusts. I think you have to experience this first-hand to really appreciate it and be more realistic about what you take on.

Experienced teams also get more decisive. Prioritising is a muscle, and the more you use it the more you strengthen it. You can make those choices, knowing that what you prioritise now doesn’t have to be the focus forever. You’ll also learn more about your colleagues perspectives – what their likely take will be and where it would be particularly helpful to get their input. All of this means you get better at prioritising over time.

Do you use backlog refinement? What impact has it had for you?

This is part of a series on agile ceremonies. We’ve already covered stand-ups and retros. Subscribe to my monthly newsletter so you don’t miss a post.

Teams benefit from two types of reflection: thinking about what they did and how they did it. Almost everyone knows they should be thinking about the former, regularly evaluating their work and reviewing how they did against their targets. But the latter gets much less attention. And this is odd, because how we work is much more within our control.

Retros, or retrospectives, are a structured way for groups to reflect on how they are working together. Retros are the agile tool I recommend more than any other. I don’t think I’ve ever worked with a team who wouldn’t benefit from some reflection time like this.

Retros are even more important if you are trying new things (which I hope you are!). When you are experimenting with your ways of working, having a regular opportunity to step back and reflect on it is really valuable.

Retros, step by step

Here’s a simple agenda for a monthly retro.

1. Check in (5 minutes): Each participant answers a quick check-in question in turn (eg “what’s been a highlight from your week?”)
2. Individual reflection(15 minutes): Give participants five minutes on each of the questions below. Ask them to note down their thoughts privately, using private mode on a virtual whiteboard like Mural, or by writing physical post-its where others can’t see them.
   • What’s gone well over the last month?
   • What’s gone less well?
   • What would we like to do differently next month?
3. Reveal and discuss (15 minutes): Turn off private mode or ask people to add their post-its to a central place under the question headings. Ask everyone to read over what’s written and group any similar post-its together. Then ask for any reflections. Are there any themes?
4. Vote (2 minutes): Give three votes to place on things they would like to explore further.
5. Problem solving (15 minutes): Look at the top 2-3 issues from voting in turn. Discuss as a group how you could approach this and what actions you would like to take.
6. Check out (5 minutes): Summarise any actions.

There’s lots of fun formats out there if you want to mix this up a bit. My favourite is Rose, Thorn, Bud, replacing the three questions in step 2 with roses to celebrate, thorns to address or buds to grow. Depending on your team, you might enjoy some more creative prompts, or you might just be happy keeping it simple!

Encouraging open reflection is the heart of a good retro

Retros work when people feel comfortable sharing both positive and negative feedback. You want to create a safe space to both celebrate what’s gone well and to tackle any issues that emerge. There’s a few things you can do to make this easier.

As with stand-ups, I recommend rotating the chair of your retros so that you are distributing the power more evenly across your team.

You might also notice a couple of things in the sample agenda above. Firstly, there’s options for people to contribute both verbally and in writing. This allows people to raise things in the way that best suits them. I also recommend allowing people to input privately, at least at first, as it can be easier to raise tricky topics this way. Setting timers for people to add comments helps too: five minutes isn’t an eternity, but it’s long enough to make it clear that you are expecting constructive feedback.

Everything we covered in how to be an unusually good facilitator also applies here. You have a head start with retros because they are an established format that’s already structured around how people think. But if you want to take your retros further, consider the questions you ask in group discussion and make sure you are comfortable with silence in meetings for the individual bits.

The regular rhythm is what makes retros work

I encourage teams to schedule retros monthly or at another regular interval. The regular rhythm means they know they have a place they can raise issues and so don’t need to bottle things up. Holding retros regularly also means the issues raised are easier to tackle, and can be tackled more promptly. There’s nothing worse than learning about something six months into a project that you could have addressed ages ago.

Of course, you need to be able to demonstrate that you are addressing issues raised in your retros. That’s why I recommend voting to choose 2-3 things to focus on, to keep it manageable. Make sure you’ve worked out who is responsible for any actions and transfer those to your Kanban board if you have one. It can also be helpful to spend a couple of minutes at the beginning of each retro reviewing what you said you’d do last time.

Do you hold retros? What works well for you?

This is part of a series on agile ceremonies. Check out the previous blog on stand-ups and subscribe to receive a monthly round-up of posts.

If you are feeling frustrated by interminable status meetings, or your team is failing to communicate enough, stand-ups might be the solution. These are quick meetings, traditionally held daily, allowing fine grain coordination. Having an efficient, regular check-in like this allows you to get clear on what you are trying to achieve together, hold each other accountable and notice if anyone needs help.

There’s some flex in the format: for non-tech teams, I usually recommend holding these weekly or twice-weekly. But there’s also an awful lot of things that get called a stand-up that are something else entirely!

The most important thing that often gets missed is that stand-ups should be quick, no more than 15 minutes or so. If they take longer than that, you’re almost certainly repeating information or discussing things that aren’t relevant to the whole team.

Stand-ups aren’t the same as a status update. They are deliberately brief, aiming only to make sure everyone is clear on what they are working on and there’s no blockers or duplication. If something needs more discussion, have a conversation outside the stand-up to resolve it.

Stand-ups, step by step

Before you start holding stand-ups, you need a Kanban board. This is a visual record of what the team is working on, split into columns like “in progress”, “blocked” and “to do” (for anything you haven’t got to yet). I recommend using something like Trello or Planner for this and keeping it simple. Don’t worry about capturing everything perfectly straight away – you will add to it as you go.

Then during your stand-up, one person should share the Kanban board on their screen. They go to each person in turn, filtering the tasks on the board for ones assigned to them.

1. First, run through the tasks under “in progress” one by one – is there anything you can tick off? Is anything unclear or blocked? 
2. Next, check if there’s anything you in the “to do” column that you want to start working on before the next meeting. If so, move it across to “in progress”. 
3. Finally, review what’s in “blocked”. Do you need to chase those tasks and move them over to work in progress?

This should only take a few minutes per person.

How not to hold stand-ups

I’ve mentioned that stand-ups should be quick. If you’re part of a stand-up that’s taking much longer than 15 minutes, you’ve probably lost sight of the purpose of the meeting. My guess is that at least some of the attendees are frustrated and feel it’s not a good use of their time!

If that’s the case, I would start by reviewing the format. Are you getting into protracted discussion about tasks that should take place elsewhere? Is the chair encouraging on swift check-ins, following the questions above and focused on work in progress rather than future tasks?

Often, lengthy stand-ups is a sign that you aren’t holding them often enough. If you can’t remember necessary context for tasks on your Kanban board, or if you are repeating things each time, try meeting more regularly. Having quicker, more effective stand-ups once or twice a week is much more helpful than winding lengthy discussions once a fortnight.

Watch out for deadlines. As in project plans, using deadlines in a stand-up slows you down and encourages you to prioritise solely based on urgency, rather than importance. As long as you are reviewing work on a regular basis, you shouldn’t need deadlines to make sure you are doing work on time.

You don’t need to update the board outside of the stand-up either – doing it there and then means you are sharing the most up-to-date information and don’t need to do additional admin outside of the meeting.

My final watch out is to make sure you haven’t got an overwhelming long list of things listed as “in progress”. Firstly, this will make your stand-ups take longer. More importantly, it also makes it harder for people to tell what they are focusing on. Prioritising a few things over a short period makes it much easier to make sustained progress. Limit the “in progress” column to things you are actually working on between now and the next meeting and don’t allow this to become unrealistic.

How to hold even better stand-ups

Ok, so you’ve got the basics of stand-ups down. How can you make them even better?

Make sure you are rotating the chair. If everyone in the team takes it in turns to run the stand-up, you all quickly learn what works well in the format. It also means you share both the work and the power that comes from facilitating. It’s a subtle nudge towards more empowered teams if everyone can chair rather than just the manager, and it makes the team more resilient for cases where the usual chair is away.

Another empowering techniques is for the chair to use coaching-style questions when they notice something is off. Saying, “This task has been blocked for a while. What do we need to take it forward?” or, “Is this set of tasks realistic?” helps everyone keep themselves accountable in a supportive way. I also like to ask “What did we notice about our stand-up today?” at the end. Often, something will come up that helps us improve the format or work better together.

If things frequently emerge in your stand-ups that need more discussion, one final idea you might try is magic time. This means blocking out a bit of time in your diaries immediately after the meeting. It’s not a meeting in itself, but if you’ve all held the time then it’s easy to grab some time with anyone you need to chat further with.

Do you hold stand-ups? What practices work for you?

This is the first in a series on agile ceremonies. Subscribe to my monthly newsletter to get a round-up of the rest of the posts.

We’ve already covered the basics you need to know to be a good facilitator and how to get better over time. But if you’re already good, how do you become a great facilitator?

Manage your energy and attention

It took me an embarrassingly long time to learn, but I’m much worse at facilitating if I’ve been in back-to-back meetings all day. Taking ten minutes before a session to review my notes, stretch my legs, take a few deep breaths and get present leads to much better results.

This is worth keeping in mind throughout the session. Take regular breaks to maintain energy levels for both you and other participants. I won’t go longer than about 90 minutes without pausing for a break, and I try to structure these so I haven’t got lots of prep to do during them.

Having a cofacilitator is enormously helpful. It feels like you can outsource a big chunk of your thinking if you can get someone else to deal with any tech issues, note taking and monitoring the chat. That allows you to focus your attention on the more impactful parts of your meeting.

Plan to adapt

The difference between a good facilitator and a great one is how well they are able to respond to unexpected things that crop up.

Three strategies that help with this:

1. Plan in detail. Yes, you might end up abandoning parts of your plan, but you’ll have a much better chance of deciding whether that’s a good idea or not if it’s thoroughly thought out. It’s particularly helpful to think in advance about what you would drop if your session runs over time.
2. Notice what’s happening and check in with the group if helpful. If you see a topic getting heated, or the conversation has swerved off the agenda, or the energy in the room flagging, say so! Be matter of fact and give some options. For example, “I’m noticing this discussion is taking longer than we originally planned. We can either move on or drop a later item from the agenda – which would you prefer?”
3. Prepare to deal with common issues. Have some go-to phrases in your pocket to help you respond to things like one person dominating the conversation or a disagreement between participants.

It’s worth spending time working out what could go wrong. As part of planning, I will list out everything I’m worried about and then consider how to address these worries one by one. This helps me head off problems and makes me more able to respond seemingly on the fly when things do go wrong. It also makes me more confident going into sessions, which in turn helps me manage my energy and attention.

Adapting your facilitation to your audience

Keep in mind as you plan:

• How well does the group know each other? You’ll need to spend more time on introductions and building trust if people haven’t met before.
• Is any of the tech unfamiliar to them? If so, share what you are using in advance, allow more time at the start and get a cofacilitator if you can.
• What power dynamics are at play? More unequal groups might need different activities to make it easier for everyone to contribute – less open discussion and more commenting in writing, for example.
• How chatty are participants likely to be? My experience is that more senior groups tend to have strong opinions and will dive right in, but more junior groups might need warming up. Plan your time accordingly. More senior groups are also less likely to do any pre-reading or pre-work, so don’t rely on that for them!

Improve your questions

One last tip: we’ve already covered how asking good questions is an essential facilitation skill. Something that made me much better at questions is coaching. Regularly coaching others (and occasionally being coached myself) has taught me so much about what makes a good, non-leading response to what’s emerging in the conversation. I’ll write more about coaching in future blogs!

This is the last in our series on learning facilitation skills. If you would like more advice like this, subscribe to my monthly newsletter.