The Urgency Trap

Continuing on with our series on common traps that organisations can fall into, it's time to look at the Urgency Trap. What's that? It's a particularly common trap and unlike most of the other traps where agile techniques tend to help avoid them, the urgency trap is one that agile teams can fall into even more easily than traditional teams. It's also a particularly dangerous trap because it can lead otherwise great teams into other traps, like the rebuild trap we looked at last time.

But what is it? Take a look at your current backlog. Now take a look at your team's long term goal. How much stuff at the top of the backlog is stuff that is strategic and aligned to your long term goal. How much is stuff that's short term, tactical and is at the top of the backlog, not because it gets you closer to your goal but because it's urgent? That bug fix. That urgent tweak to a feature that someone demanded. That urgent update to the terms and conditions because someone in legal found a problem. What's the ratio? More than 50% long term and strategic? Trend is steady? You are probably OK. Less than 50%? Percentage of urgent work is creeping up and displacing more and more strategic work? Welcome to the urgency trap.

This is a trap that all teams can fall into but especially agile teams. The extra planning flexibility built into agile methodologies can be a hindrance as well as a help to a team. Traditional teams are somewhat insulated from the urgency trap because they are inflexible. They make a plan and generally stick to it. They insulate themselves from new, urgent work that comes in through complex change request processes.

Agile teams don't have those protections. If something urgent comes up, it's very easy to just add it to the backlog. Then at sprint planning time, well, it's urgent is't it? It needs to be done now, so let's put it at the top and get it done. This is really common in agile teams that are part way through building whatever it is they are building. They have a long backlog of stuff they need to add, but the first part (or parts) are in production, so the team is responsible for both adding new features and supporting existing ones.

Now, that's not really a problem if you are careful, that's the planning flexibility that agile techniques were designed for. That's what allows agile teams to adapt and deliver what the business is really asking for. The problem occurs when the amount of urgent work starts to swamp the other work in the backlog - the new product or features that the team is really there to deliver. The team just becomes a deliverer of short term tweaks and fixes as demanded by the business, rather than delivering the real long term value that they were created for. Agile planning can quite easily start to prioritise the urgent above the important.

It's really easy for the amount of urgent work to creep up over time as well. First it's a couple of things and the team re-prioritises and gets them done. Then people see that urgent work gets done fast and they really want that tweak done now so they can hit their sales target for the month so they start to tag their requests with urgent as well. Over time, pretty much everything (except the team's long term backlog) is urgent. The top of the backlog is jammed with urgent requests and that's all the team does.

Of course, when everything is urgent, nothing is urgent. The team has no information on what things are actually really, really urgent and what's just someone wants it really badly urgent, so they end up working on the wrong things. Some teams end up with multiple urgent states to try to distinguish. Is it just urgent or is it super urgent? Over time, of course, everything will become super urgent and they will need an "OMG it's on fire!" urgent state and so on. Here's a hint - if you have multiple urgent or expedite states, you are deep in the urgency trap.

Once in the urgency trap, the team is consumed with servicing urgent requests. Often quality drops and tactical solutions become the norm. Architectures get compromised, technical debt mounts. Often the team ends up in the rebuild trap soon after.

To avoid the trap (or to get out once you are in), you need to take a few approaches depending on why there is so much urgent work in the backlog. If there is legitimately a lot of urgent work in the backlog because of real, urgent business changes, and those business changes are going to keep coming at that rate over the long term (not just temporary teething problems with a new product in production that will dry up soon), then maybe you need to talk to someone about additional capacity to handle these changes as well as the original purpose of the team.

If there are a lot of urgent things in the backlog and those things are mostly bug fixes, maybe you have an underlying quality problem. You need to stop and divide your time between fixing the urgent bugs and fixing the underlying quality problem to stop so many new bugs coming in. Once the bugs are fixed and the quality issue resolved, move back to delivering the long term backlog. This will need negotiation on time lines with sponsors which will be an uncomfortable conversation but it's the only way out.

If there is a lot of urgent work in the backlog because people have decided that it's a good way to get stuff done quickly then it's time for a backlog cleanup. Get a senior stakeholder plus all the requesters of this "urgent" work in a room and ask "How urgent is this really?" It's amazing how much of the amazingly urgent work will melt away under serious scrutiny. Chuck out the junk. Prioritise the rest properly. Then you need to make sure that you don't end up in that trap again. Have some clear criteria for what constitutes an urgent piece of work. Set a WIP limit for urgent work - only 2 urgent requests per sprint for example. If a third comes in, which of the other two will it replace? The loser goes on the backlog for next time. Force the organisation to prioritise properly. Take control of your backlog.

If you keep control of your backlog and make sure that urgent work is really urgent and not just something someone wants done quickly you can escape from (or better still, never get into) the urgency trap.