Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to John D Carmack and Random Acts of IT Project Management with appropriate and specific direction to the original content.

Tech

Posts Tagged ‘remediation’

Over at Agile Chronicles, Mike Cottmeyer posted “Handling Support on Agile Teams”, but as even he himself says, “This is a problem not unique to agile teams. Software organizations have been struggling with this one for years.”

Indeed, he is most correct. How to account for time dedicated to support once the code is out in the open? I have noticed, though, that the more seasoned the team, both as individuals and as a unit, the less defects are likely to be produced. Yes, experience is the best teacher, but it isn’t necessarily the most efficient one.

Cottmeyer lists 3 options for dealing with defects. Each has its strengths and weaknesses. Personally, I think a lot on the exact method you pick is going to have a lot to do with the overall environment, the types and number of current projects and the overall effectiveness of the developers. I use “effectiveness” as not only productivity, but experience level and ability to task switch.

That last point should not be underrated. The ability of any individual to multitask is going to have a profound effect upon the duration and quality of their work.

However, here are some other factors to keep in mind:

Responsibility. How often is Jane going to fix John’s code without resentment building up? Is John mature enough to at least accept responsibility for his mistake and learn from it?

Amount and severity of defects. Some defects can wait. Are you getting an abnormal number of defects? Of course, you’ll need some type of historical data to go on, but if there are an abnormal number, it might be time to do a triage or at least a special after action review.

Corrective to preventative measures. It isn’t enough to just fix the immediate problem, but for the team to learn how to avoid it next time.

Seniority mix of the team. I have long argued that you want to avoid all junior developers for a team. However, you also want to avoid all senior developers on a team. You want a mix, but no more than 50% new developers and no less than 50% experienced ones. Why? Because you need mentoring, coaching and the examples of the senior developers to grow the junior ones. However, an injection of new ideas is not a bad thing, either. Not only that, but a team of all senior developers can become an ego party. Frankly, it is not the most efficient way to get work done, and neither is it all that entertaining.

One of the key requirements of being a manager, but especially a project manager, is flexibility. How you deal with defects will test your skills and bend you out of shape if you allow it.