Skip to content
Home » Blogs » cspag's blog

Fighting fires the agile way

March 5, 2008 by cspag

image Let's face it, no matter where you work, fires flare up from time to time. Some are serious and need to be addressed, some are just smoldering and can be put off for a short time, and some are just people yelling fire when there is no fire. Some organizations are perpetually in fire drill mode and can't break the habit. So, if you're an agile organization and your agile teams are committed to completing their iteration tasks, how do you fight these fires without interrupting your agile teams Even if you allow a buffer of time within your iteration planning for handling unexpected requests, you still run the risk of distracting your development teams with potentially harmful context switching.

An interesting solution may be to assemble an agile fire fighting team. Essentially, the team would be composed of developers from different project teams. The fire fighting team would be assembled for two-week iterations (synchronized with your project iterations) and team members would rotate in and out of the team. One team member would be the fire captain. The fire captain is responsible for handling fire drill requests, triaging them, prioritizing them, and working with the fire fighting team to task them out. During their rotation on the fire fighting team, team members respond to urgent requests and work on them the same way they would any other task in an iteration, committing to address them by the conclusion of the iteration. What if there are no fires to fight? Well, don't get too excited...it's not off to the beach for the fire fighting team. If there are no fires, team members can address defects that may exist on their current project backlogs, they can work on documentation tasks (I knew you'd love that), or they can use the time as part of their hackathon innovation allowance.

My personal preference is that organizations work as hard as they can to move beyond the fire drill mode. I think it is harmful to your development teams, reduces overall quality and value you are delivering to your customers, and ultimately it will impact you organization in a negative way. That said, if you can't wean yourself off the fire drill mentality, consider putting together a fire fighting team.

Bookmark/Search this post with:
  • Delicious
  • Digg
  • StumbleUpon
  • Propeller
  • Reddit
  • Technorati
Permalink

Comments

I've made a career out of

March 5, 2008 by Robert Fischer (not verified), 43 weeks 5 days ago
Comment id: 1472

I've made a career out of triaging fire fighting requests -- hence my nom de plume "Smokejumper Consulting". Basically, what I've discovered is that if your project is in "fire fighting" mode, the only way you're going to solve it is by having a point-of-contact to take the hit for the development staff and triage the firefighting requests. And, more often than not, the "firefighting request" is more a general sense of panic coming out of bad communication -- the business believes that if their priority isn't the highest, it won't get done.

The firefighting triage role is the classic ScrumMaster position, but you can also have a senior technical person with tact and patience act in this role. You are taking a hit in that this person won't be writing much in the way of code, but they can go a long way in improving morale and increasing productivity.

Having a team of firefighters seems like a nice idea -- I've seen it implemented as "implementation teams"/"productionalization teams" and internal consulting groups, and I've even seen it work once. The biggest political problem, though, is that it tends to end up populated with the least qualified developers in the company. Basically, if someone is a good developer, they are a hot commodity and viciously defended by their management -- they're sold as too critical to the project's success to be put into rotation. And so the only people left to make up the internal consulting group are the people that nobody considers worth fighting over.

The one time I saw the internal consulting group work, it was because the internal consulting group was "higher ranked" than the other development positions. You got promoted out of your team and into the internal consulting group, with the associated pay raise, better cube, and everything. This made it something which the developers wanted to be on, at which point it became a lot harder for the PMs to hold people onto their teams.

Now, if you are an executive in your company and are able to set up a mandatory rotation system, that'd be fine solution to the problem. If you do that, though, you need to watch out for middle management trying to game the system in order to keep their favorite developers in their pocket.

Best engineers - out of projects

March 6, 2008 by Artem, 43 weeks 4 days ago
Comment id: 1473

I also think that if you need special forces, the best people both in army and software development should be in the special forces, not in regular teams. And if from time to time they have nothing to do - well, that's the price of a guaranteed help when it is needed.

Ideally though, it's a good idea to work for minimizing the need for the special squad.

Every company has one

March 6, 2008 by T-Enterprise (not verified), 43 weeks 4 days ago
Comment id: 1474

I would go as far as to say most companies do have one in some way or form. Good article mate.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.

Best of AgileSoftwareDevelopment.com