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.