As you've read in a recent blog post I focused on Brooks' Law. It is one of those ugly truths of software development that we never seem to learn to escape. This led me to thinking about a follow-up to the law and book, that of the Mythical Man Day.
We have all experienced this one as well.
Well intentioned software development managers or project managers ask you how long it will take you to perform some bit of work. You'll typically give them an estimate in units of days or weeks. They might challenge you a bit on your estimates and you might give in—in one direction or the other. Eventually, you'll come to a loose agreement on the appropriate level of effort, again, in agreed units.
Read More
This post is a continuation…
Can you drive a team to zero productivity?
One question I always ask myself when fielding these offers of assistance is – Can I drive my team to negative or near zero performance? The answer is obvious, supporting the MMM, but hard to resist in the heat of crunch mode when the pressure is on.
I'll give you a simple, but extreme sort of answer. Let's say you have a team of 4 developers and you get behind schedule. You get offered an offshore team to help your efforts and recover the schedule. The offshore team has an onshore group leader, 3 onshore developers and 5 offshore developers. From your executives or stakeholders point of view, this appears quite helpful. In fact, they're literally tripling your staff. However, in this situation I would bet that the overall performance is driven to zero for at least 2-4 weeks as the new team is trained and assimilated.
I would argue that the neutral impact would be much longer, as the existing team catches up on delayed work and the new players figure out how to effectively contribute. Say perhaps 4-6 weeks. At this point the "step" becomes a gradual productivity curve as new team members normalize to the average performance level of the existing team. This could take anywhere from 1-3 months or more depending on a wide variety of factors.
You might argue with me over the time estimates, but the ramp-up step function itself proves to be a consistent law within technical teams. You ignore it, as Brooks' points out, at your peril. You can improve or at least plan for team additions by better understanding the variety of factors that come into play.
Step Function Factors
The following are some of the critical factors that influence the ramp-up curve and step function for adding people to a team.
- Challenge level of the domain – How "hard" is the product and technical domain in which the team is operating? How long does it typically take engineers to become comfortable?
- Overall domain experience of the team – Here the emphasis is on the product domain. I've seen some that require months and even years to achieve expert capabilities.
- Functional level of team – The overall experience composition level of the team—including junior & senior engineers, leaders and domain experts.
- Process maturity of the environment – To what degree do processes and practices enable new team members to quickly come up to speed? The agile methods are actually not very good at this.
- # of existing and incoming team members – Numbers really matter, particularly if you have a large incoming group to a smaller group. And its not just about technology, culture and team fit matter too.
- Physically where the project is within its lifecycle – It is much easier to add people early on in a project than it is in the Endgame.
My experience is that most managers underestimate the ramp-up of new engineers. Worse than that, they don't anticipate the impact to existing team members. This can also occur with experienced engineers who are struggling with new technologies and their overall performance, perhaps tapping onto more experience engineers or group leaders for assistance.
6th Sense Analytics is a singular tool that provides detailed insight into these nuances of your own and your team's performance without the burden of data collection. In your future projects, I encourage you to analyze your team's and your own performance so that you can effectively defend against the magnetic attractions that lead to Brooks' Law.
Study your Ramp Curves
You'll also want to become intimately familiar with the dynamics of adding resources within your teams. In a 6th Sense Analytics environment, this equates to monitoring individual and team based Active Times during the course of project work. Find a team where new member(s) have been added and review the impacts, such as:
- How quickly do new addition(s) ramp-up on Active Time to meet average levels within their specific group or role?
- If they've come from another group or technical focus, what is the difference in Active Time between the different activities?
- What is the impact (drain) to existing developers on the team? And to the team leader or assigned mentor?
All of this leads to more accurately predicting the overall contribution levels as new team members arrive and existing team members leave project efforts, which helps your planning and ability to react to project ramps – and reply more effectively to those "help" offers mentioned earlier.
I usually experience a sort of step function during ramp-up. Usually I'll apply a 33% rule when planning for resources. Typically that implies they will –
- Have a negative impact for the first 33% of time (let's say a month for relatively inexperienced engineers
- Have a neutral impact for the next 33%, again let's use a month as a baseline
- Begin having a positive impact the next 33%, another month
- Then ramp-up to average contribution rates within the team
This effect is further illustrated in Tom DeMarco's book The Deadline. In Chapter 10 he presents the concept of usable staff, which quantifies the above relationship across an entire team.
I should generally put in a plug for DeMarco and Tim Lister as having also explored this in their earlier work, Peopleware – Productive Projects and Teams. In The Deadline there are a set of models presented that take this one step further. He alludes to programming a model that can perform what-if scenarios for usable staff calculations.
If you think about it, 6th Sense Analytics collected Active Time data would be a wonderful calibration mechanism for any modeling tool. It would support the determination of real-time usable staff under dynamic project conditions and require no data collection effort. If anyone has the time, I'd love to work with you on setting up an Excel (or other) model that we could connect to 6th Sense Analytics. I think the potential of such a tool would be very exciting and quite useful to our community. If you're interested, email us at info [@] 6sa.com.
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...
