Remember Brooks’ Law?
It has been a few years beyond the 25th Anniversary of Fred Brooks wonderful book the Mythical Man-Month, which I hope hasn't gotten lost in time. I consider it, and Tracy Kidder's Soul of a New Machine, to be two of the most important development management "experience papers" ever published. These guys weren't talking about academic principles or disconnected hypothesis, no, they were recounting real lessons from real software projects.
Even more surprisingly, I still find the lessons from each nearly as relevant today as they were when they were written, which can be depressing if you consider how little we've learned from our mistakes. Oh well, back to the MMM (Mythical Man-Month).
One of the fundamental principles that Brooks identified within software projects was Brooks' Law, simply stated as—"Adding manpower to a late software project makes it later". I think we've all experienced this in action. Your project starts falling behind schedule. Your internal reaction is to apply more pressure to your team to "make up" the time and recover the project. External stakeholder and executive pressure can often take a different direction, looking to add people wherever possible to recover the schedule.
I can't count the number of times I've been offered "help" of this kind from well and not so well intentioned exec's, project managers, and others. Later on, when I began leading testing teams, the offers surprisingly even increased. Partly because schedule pressure moves downstream, so testing is always compressed. Partly because many think that almost anyone can test – school children, boy scouts, customers, etc. But that is fodder for another post...
Help Defense
Often if you simply say no to these offers, you'll come off appearing stubborn, inflexible or generally resistant, none of which are perceptions you want to create. Additionally, there will be times when these offers can actually help you resolve schedule pressure and apply corrective action, although rarely exactly as envisioned within the offer, but it can help nonetheless.
The key is to be able to understand the nuance of your teams' performance and truly understand the dynamics of adding and removing developers and testers before you actually get asked these questions. That way you can reply with an informed perspective on truly what can be done to improve the situation by adding people. And conversely, what will actually worsen the situation (as defined by Brooks' Law) by adding people.
Study Your Teams' Capabilities
Your first position of defense comes from truly understanding the performance capabilities of your team, often at a detailed individual and sub-group level. For example, if you have a small 3-4 person database development group, you should understand:
- What sorts of artifacts they typically create (scripts, stored procedures, DB architecture & configurations, etc.)
- Typical delivery times for different "sizes" of deliverables
- Who is the highest performer in Active Time and in contributed LOC and other meaningful artifacts?
- Conversely who is the lowest? And what is the average across the entire group?
- What the exact performance impact would be if you lost a person?
This data gathering is not for performance commentary or rewards. Rather, you're looking to understand the detailed tempo for contributions within the team in case you fall behind schedule or lose a person. Then you'll much more fully understand the impact and be able to plan and react accordingly.
One of the valuable aspects of velocity based planning, as mentioned in a previous post, is that it naturally compensates for these sorts of things. Often though, you can't simply wait for velocity to unfold and illustrate the impacts, rather, you must have a strong sense in advance.
This post is continued here...
Previous Post:
OSCON Recap — ‘P’ is for Passion
Next Post:
Brooks’ Law Continued — Team Ramp-up
