“The team just isn’t demonstrating a sense of urgency.“
The manager looked earnestly at me across the table.
I took a deep breath. “If I may clarify. Is your wish that the team understands the urgency of the situation, or that they demonstrate a sense of … panic?”
This was supposed to be one of those rhetorical questions. Obviously nobody would pick –
“The second one.”
“Really? You want them to be visibly panicking?”
“Yes”
“I hope you realize that having a sense of panic does not generate results.”
The manager smiled softly. “It always has.”
Of course it has. Instilling a sense of panic generates visible activity. A lot of scurrying about, and looking busy. In the realm of motivation via carrots and sticks, panic is most definitely the result of application of the stick.
“Allow me to put that another way. Panic does not get you to a solution faster; it just makes getting there more painful.”
I have had variations on this argument with a dozen managers over the years. It all stems from the same source — a basic belief that without a steady application of management pressure, development teams would lapse into a motionless stupor. The notion is completely at odds with attempts to create a self-directed agile culture.
“So what I hear you saying, is that you want to be able to walk into the team room during an emergency situation, and see them running around like a bunch of headless chickens.”
“Yes.”
“Then I’m afraid we have a problem. You see, I have been coaching them into taking a very strategic approach to emergencies like this.” I ticked off the points with my fingers, “1. Get somebody addressing the immediate problem. 2. Get somebody else figuring out how it happened. 3. Get somebody to figure out how to prevent it from happening again. Calm. Purposeful. Not panic. Panic causes wasted effort. It causes them to act before they think, and possibly waste precious time.”
My mind immediately tried to conjure a picture of that moment when the team members worked out who among them would be solving the problem, and who would be providing the illusion of motion – probably in the form of a team member dressed in sack-cloth, their face smeared with ashes, sitting in the hallway outside the room wringing their hands and chanting, “Oh woe is me…” In other words, turning a productive member of the team into an unproductive one, for the sake of political theater.
In the transparent world of scrum and agile, the manager was asking for a new kind of information radiator. A PANIC Radiator. Something akin to a DefCon rating, or perhaps the Terrorism Threat scale. The trick would be to figure out how to provide the radiator without actually instilling the actual destructive panic sense among the team members.
A little clarification is in order here. Normally in scrum, there is no way to add work – emergency or otherwise to a sprint backlog once the sprint is underway. This particular group shares the responsibility to develop new functionality while at the same time providing responsive support for customer issues. Before an issue ever comes to the team, it has already survived attempts to deflect it by the scrum master, and has resisted attempts to have it delayed until the next sprint. These are rare issues that get through the net, and must be acted upon — usually with sponsorship from a very high level. One of the things the team that takes the issue on must do, is evaluate it against their existing workload. If it will impact their sprint goal, then they work with the product owner to hot-swap this new issue in and an existing piece of work out of the sprint.
So back to the panic radiator. Often in a coaching situation, it is not appropriate to simply dismiss unrealistic requests. You have to strike a balance between what they are asking for, and what their actual need is. Somehow, the team in question wasn’t bringing visibility to the work they were doing. There had to be a way to allow anyone to walk into the room and know that there was a hot issue in play, that it was being worked on, and what else was being done in relation to the issue. It sounded like a task board. In this particular work space there are two teams, each with their own scrum board and their own tasks. The first obvious response would be to make sure that the team addressing the issue should have the emergency item, and the tasks associated with it on their regular work board. But that presented the possibility that half the people in the room wouldn’t be able to provide status on each emergency issue. That ran the risk of triggering another “lack of urgency” accusation.
We presented the problem to the teams, explaining that they needed to come up with a way of bringing visibility to hot issues in a way that provided status to anyone who cared to look for it. More importantly, the solution should have minimal impact on their normal flow of work.
The solution was deceptively simple: An emergency issue board. Any hot job that comes in is placed in the todo column on that board. On any day that there is open issues on the board, there is a third daily scrum held (one normal scrum meeting for each team, and one combined scrum meeting for the issue board). When there is a new issue, the two teams discuss the issue at the extra status meeting, and somebody takes ownership of it, putting their name on the issue. Tasks are then created to represent the work needed to address the issue. These tasks are tracked to completion. The third meeting is skipped if everything on the wall is complete. The beauty of the solution is that anyone can walk up to the board, see the issues, see who is working on them, and more importantly, see when they are completed. All without breaking a sweat.
