I happened across a thread on the ScrumDevelopment list discussing putting out fires – in other words having time/resources available during iterations for production support that was unforeseen.
Having spent 7 years with on a fire department, the phrase has a special meaning to me. However, I started thinking about the parallels between the production resources needed on a project and fire departments themselves.
Most of the U.S is covered not by paid fire departments, but by volunteers. This means if you have a fire, these people leave their work, their homes, their warm beds and families to drive down to the station, pick up the truck, and head over. Response times can range from 5-30 minutes or more for someone to get there. And for most places, that’s acceptable – when you run 10 calls a year, paying people to sit there is hard to justify.
However, the department I worked in, we had stations that would average 80-90 calls /a day/ between 3 trucks. In this more urban setting, we had no choice but to pay people to be there – there were too many fires to put out, and the fires that did catch could be very costly.
(One of the first fires when I started was a multi-multi million dollar mansion. They were adding on a 3000 sq ft library and the contractor wired something wrong)
So, it would seem to me that the process would be similar on projects. If you have lots of fires to put out, or if the fires are very costly, you take the hit of the cost to pay people to sit just in case. If you are plugging away with very rare production support issues, you handle it as it comes in. I don’t think either way is particularly worse than the other – sometimes you just can’t help production support issues.