The Agile Response to a P1 Incident

How should a team respond to change?

The simple answer is “they should respond by being agile”.

If there’s one concept about agility that sceptical managers have caught onto it’s this one. When change happens, they expect that a truly agile team will be able to turn on a dime. You can hardly blame them, it sounds like a great idea. It suggests that perhaps managers don’t need to stabilise the working environment. They just need to pass change on. The teams will be able to deal with the impact…if they’re any good.

After all, aren’t they meant to be agile?

Of course, team members will have a rather different interpretation of this. They’ll tell you that agility isn’t about being reactive – it’s about responding to change in a controlled manner. With seemingly limitless demands on the team, and clearly finite resources, prioritisation becomes essential. Agile teams will work from an ordered backlog, and they’ll plan to deliver value by drawing work requests out of that queue. In other words they plan to follow an agile process…and that means things like “Sprint Planning” can still happen.

So let’s ask the question again – how should a team respond to change? A better answer is “they should respond by following agile rules”.

It isn’t about turning on a dime, it’s about following rules, and it’s important to understand how those rules differ between agile methods. Nowhere is this made more clear than in the way agile teams respond to a “P1 Incident”. It’s common in service management to rank incidents by priority. A P1 (Priority 1) is considered to be the highest – the business itself is threatened. When a P1 happens the expectation is that all hands will man the pumps.

So what does that mean for an agile team that plays by the rules of backlog management?

Well, in the case of a Lean-Kanban team, the response model is fairly straightforward. Priority incidents can be moved to the top of the backlog so they are actioned as soon as the next team member becomes available. Alternatively the quality of service can be varied. As soon as a P1 is raised a ticket (card) will be placed in a fast-track lane on the Kanban board. The team will stop what they are working on, mark their tickets as  impeded, and swarm over the P1. Once a response has been planned those members who won’t be involved can return to their original work.

A Scrum team has a different agile response. They’re rigged for the incremental de-risking of project scope, and plan to meet a Sprint Goal each iteration. If they have to drop everything for a P1, then that goal may no longer be achievable and the iteration could have to be terminated. Clearly they aren’t geared to be as immediate in their response as a Lean Kanban, but not all managers will understand or appreciate that point.

Interestingly, some companies have dedicated “incident rooms” to which key personnel are expected to decamp should a P1 occur. These are clearly modelled on the incident rooms of the emergency services, the idea being that if responders are co-located then the crisis should be handled more efficiently.

In an agile context however, they are something of an anti-pattern. In a genuinely agile organisation the responders will already be co-located along with the resources needed, and information radiators will be in place to keep stakeholders updated.

As long as the agile models in use are understood a P1 incident can be handled without recourse to special measures.