← Home

Removing the Word Urgent from Software Development

First published in January 2021

The Problem with “Urgent”

Before you start reading this post, think about times in your career when you’ve been told that something is urgent, or told someone that something must be done “urgently”. In any of the examples that you’ve come up with has either party immediately understood the timeline for the task (and also the reasoning for the urgency)?

My problem with “urgent” is that it doesn’t mean anything to anyone. In my career I’ve had people tell me that a code change needed releasing urgently, and they’ve meant any time within the next working week. I’ve also had people assume that because they’ve told me something is urgent, that it should be my immediate priority and completed within the hour (at the sacrifice of any other task I may have been working on).

It is all too common in software development, that people will prioritise tasks from their own agenda without the bigger picture of what is going on in the project - this can cause the stated objectives of the current development phase to slip and in severe cases team members can feel compelled to make up their routine tasks by putting in additional hours. You don’t want this, because this is where things get rushed, quality starts to drop and people get burned out.

What is the Alternative?

The short answer here, is anything with a definition. Different solutions will suit different organisations but I’ll give a couple of quick examples that I’ve used before.

The simplest example I can give you is the “now or tomorrow” approach. If something is truly business impacting - e.g. your product is down/offline - then it gets dealt with now. If not then it gets discussed and prioritised on your next scheduled call (I’d normally allow it to bleed into the daily standup the next day).

A slightly more common approach is P1 through to PX. The less priority levels, the simpler the system and therefore the better. In this system, only a P1 should impact work that is in flight - a P2 may get done in the current sprint (in place of something else) and P3 plus get deferred to a future sprint.

Determining Priority

Once you have the vocabulary to replace Urgent, you need the criteria for determining which priority level a request will fit into. If you don’t do this bit, a stakeholder may try to abuse the system and make everything a P1 (unfortunately this does really happen).

You can do this by listing out your priority levels and a set of qualifying criteria e.g.

P1

The above is a very brief example of some items that may fall into a P1 status. I’m happy to share a more complete example if you get in touch!

The P1 Team

In the ideal world high priority production issues should come into a dedicated support and maintenance team so that the sprint/development team don’t get interrupted. Not all organisations will have this separation but you can rotate people in and out of the support team on a regular basis.

From experience it is a hard sell to hire someone as a “support developer” - for some reason the industry has given this title some fairly negative connotations. I favour the everyone does support approach. It removes hierarchy amongst developers and increases the idea that we are all “on the same team”.

Dealing with Resistance

Making organisational change will always encounter some resistance from people who were happy with “how things were”. Be prepared to spend time talking to those resisters to explain your motivation - and ask for time for them to see the benefits!

As a tech leader, be aware of enforcing changes upon your team. Involve them in the process and make sure that they know that you will listen to feedback. In my last role, our process was tweaked week to week based on feedback from developers and stakeholders.

Creating a Common Vocabulary

Once you’ve decided how you are going to prioritise issues, the next step is top stop people saying that things are urgent and use the agreed terminology.

The only way I’ve found to do this effectively is to be the irritating pedant who chimes in with “We don’t say urgent around here!” whenever the U word is uttered. I am completely aware of the muttering under the breath in response, and how I come across to some in this situation - but I’m prepared to take that for the wider benefit.

You only have the be that person for a few weeks ideally. In my experience implementing any change that reduces stress is popular and people should naturally pick up the baton from you and squash the U word once the benefits have taken effect.

The common vocabulary is a wider concept that can be applied across a team - it is an extension of the “Ubiquitous Language” idea Eric Evans uses in his book Domain Driven Design.

Interesting! I’d like to Talk More

Sure, drop me a message. I’m consulting at the moment and am keen to help software teams improve!

← Home