Mythical Man Day — The Fallacy Continued
As customers scale up using 6th Sense Analytics and our user base builds, we're noticing the same sort of trends although slightly less than our metrics – around 15-20 hours of Active Time within the user base, representing about 25% of their overall time. In fact, there are cases where it's slightly less than that. The user base is still learning how to effectively gather, measure and interpret Active Time within their teams.
One customer reported a problem to us regarding Active Time. It seemed some of their best software developers were not contributing even at the average rates. This caused them some serious concern within the team. Their first reaction was to blame faulty data collection. But that wasn't the problem and, after calming down, they looked for the real cause.
It turns out that they, the senior developers, were spending a serious amount of time providing technical leadership and mentoring to junior and less skilled members of the team. This created the perception that the remainder of the team was contributing more than they. Were they? Of course not! In fact, they were increasing the overall capacity of their teams and should be recognized for that. This is a good example of why you shouldn't interpret Active Time blindly.
Finally, here's the dirty little secret (but we all knew it anyway)...
It seems that the reality of the Mythical Man Day is that technical teams are able to truly work at levels that are much less than we are placing in our plans and schedules. I'd guess that the majority of teams contribute, truly productively, at between 40-50% of their working hours. Everything else is fluff around organizational, project management, and personal dynamics and wastes valuable time. The surprise is how much of that is going on. And no wonder so many schedules over-run!
So, in your next scheduling effort, review your Active Time for the team as a metric to determine a more realistic “conversion factor” when scheduling your estimates. If you don't have a place to start from, then use 40-50% until you get a better feel for your historical performance. And ALWAYS adjust the factor as you gain more historical perspective.
The reality even gets more interesting. Guess what, the entire team doesn't have a productivity factor, individuals do! And we need to start acknowledging that in our planning and scheduling as well.
Instead of applying a global or team wide productivity conversion factor, I suggest that you use Active Time on an individual basis for your estimates. I've already discussed several ways to do this in the blog before. One method is simply using Active Time based velocity to predict ongoing performance – at a team or in this case individual developer level. However, many organizations struggle with the notion of velocity because it connects to the Agile methodologies and it flies in the face of traditional project planning.
Another approach is to use Active Time and PROBE for estimates. Again, we discussed this superficially in a previous post and I will follow-up with more application notes in a future post.
A final approach is to have yourself or your team's estimate and produce plans as you always have. That's relatively simple. However, instead of adjusting your estimates based on some formula or special factor, use individual Active Time (Active Hours) to adjust them for scheduling purposes. If you worked on similar tasks then take the average Active Time from a similar activity and use it. If you're working on a variety of unfamiliar tasks, then you may need to review and use other team member's Active Time who've work on these sorts of things and “seed” yours with that until you get enough data.
To combat the Mythical Man Day fallacy, you simply need to use more realistic productivity factors when scheduling work. Using Active Time can significantly raise the realism in your scheduling and ultimately narrow the uncertainty in your schedules. And who doesn't want to actually hit their schedules every so often?
Previous Post:
The Mythical Man Day — Another Fallacy of Software Development
Next Post:
Creating the High Performance Team
