Fire drill, followed by "Why isn't this done?"

The Problem

Interruptions in your work are very costly. They usually come in the form of an expedited request to satisfy the craving of some stakeholder. If the craving is local to that stakeholder, there is a significant cost to the overall system when the interruption is serviced.

We call these interruptions by many names. Here are a few you probably recognize:

• Fire drill
• Context switch
• Shoulder tap
• Urgent request
• Pet project of the CxO

Once the fire drill is over, the stakeholder offers up this question, "Where is my top priority feature?"

"You mean the one we had to put on hold to put our your fire?" you reply.

You've been there before, I know you have. Here is what I'm currently trying.

The Solution

Make the interruption as visible as possible on your information radiator and show how it prevented other work in progress from getting your attention.

I use Trello currently, and I've started adding the image below as a custom sticker to Trello cards that are deemed "fire drills."

It makes the card on the Trello board really come to life! Here is a static image of a card with the sticker.

At the end of your iterations, you can quickly see which items were fire drills. If you track metrics, such as, "How many fire drills did we have this week?" or "How many items were compromised due to fire drills this week?" you begin to write a story to stakeholders about the cost of their expedited request.

Exhibit A

We just experienced one such fire drill on one of our teams. The stakeholder imposed a request on the team and the team serviced the request. When the fire drill was over, the team lead sent this response:

Dear Stakeholder, 

We had to drop everything we were working on yesterday for your fire drill issue and missed our internal code delivery deadline for your other priorities. Because we follow two-week sprints and release cycles, this means we have to delay the release your prior "top priority" feature until two weeks later. 

Ever your humble servant, 

The Team Lead

Tell me when my cukes are done

So your test suite takes a few minutes to run. That is valuable time to go check Twitter. Of course, you don't want to get sucked too far into the Twitterverse and want to only read tweets while rake is running your suite.

Let iTerm tell you when your tests are done! iTerm will let you define a trigger and then perform an action when your trigger is set off.

Let's assume that rake will spit out some text when your cukes are all done:

Took 65.38276 seconds

Convert that to a regular expression and use it as your iTerm trigger:

^Took \d+.\d+ seconds

Now, let's define the trigger. When your iTerm matches that regular expression, iTerm will execute a the /usr/bin/say command on the Mac to convert some text to speech.

Open your iTerm preferences.

Click the "Edit" button in the Triggers section and use your regular expression to define the trigger:

Now, when your iTerm encounters text like "Took 65.1234 seconds" your Mac will say "Your tests are done."