Joel Spolsky points to a blog entry by Dmitri Zimine that does a good job pointing out the problem with interruptions when a software developer or team needs to be heads-down on a project. The posts are more than a month old, but they're still just as relevant. As an agile development team manager, I know a significant part of my job is to provide a layer of abstraction between the dev staff and everything else in the world. Interruptions and distractions have a compounding, maybe even exponential delay effect on major software projects - a half-day interruption can result in several days of lost productivity (especially if the half day is scattered an hour or half-hour at a time over a couple days, for example).

I've often wrestled with trying to strike a balance between what needs to get done on some project and the rest of the needs (and wants) that are out there. Ultimately, here is what I have come up with:
Bugs that impact real customers simply have to be fixed. Bugs happen, and so fixing happens. How important and impactful the bug is determines the priority of the effort and whether or not (and when) to interrupt the programmers. It's my job to put myself in the communication loop, as a filter. I have fallen down on the job a bit in that regard recently, partly because of my work travel schedule. I need to re-insert myself to enable the development staff do their jobs even better. It seems obvious but it's worth saying: You cannot make everyone happy all the time, and you should never try to do so. All you'll get is disappointment, and that's not a worthy goal. Nothing is ever as big a deal as it seems. Everyone has their own priorities, and it's human nature for people to make their own priorities seem highest. But that's not the way it really works. See Number 2, above, for a solution. - Focused developer and QA people are happy. Distracted ones are grumpy, much less productive and complain a lot. In other words, there is a domino effect. Professionals expect their managers to help them do their jobs well, and that's a reasonable expectation. My job is to hire good people, make sure they have what they need, and then let them do what they do best.

I truly enjoy working with my team in an agile world. It's always a fight to strike that perfect balance, and since true perfection is impossible, it's always a moving target. But a good manager will stay on top of that target, anticipate problems, adjust to the environment, and head those pesky issues off at the pass whenever possible.

For the record, I'm about as far from an optimal agile dev team manager as one could find. I am learning something new every day, much of it OTJ style, and there are other people where I work that are quite literally pros in the agile management field. For all I know, they may have something to say that contradicts what I've espoused. Should be interesting. Technorati tags: Agile, Management, Developers, Software, Programming