6th Sense Analytics

Creating the High Performance Team, Continued…

Pareto -- Finding Your High Performers

In an earlier post, I discussed the use of the Pareto Principal or 80:20 rule in a variety of technical situations. One I lightly touched on was applying Pareto to your teams to find identify the top 20% of your team that was contributing to roughly 80% of your work. I continue to struggle with this notion as a leader. I want to subscribe to standard views that team performance follows a more balanced distribution and that my role as a leader is to be constantly improving my overall team.

I do subscribe to this somewhat. However, I've come to the conclusion that it doesn't truly recognize, acknowledge and grow the true stars in your team -- your top performers. You spend so much time working with everyone to improve that you can easily forget your strongest and best engineers. And top performers come in a variety of flavors, depending on the situation, so don't think this has to be an exclusive club.

Creating the High Performance Team

In the book First, Break All The Rules What the Worlds Greatest Managers Do Differently, Marcus Buckingham and Curt Coffman share a truth if you will regarding building teams. I think it flies a bit in the face of traditional wisdom and wanted to bring out their views. They have captured the following revolutionary insight common to great managers:

1) People dont change that much (when selecting someone, select for talent)

2) Dont waste time trying to put in what was left out (when setting expectations, define the right outcomes)

3) Try to draw out what was left in (when motivating someone, focus on their strengths)

4) That is hard enough (when developing someone, help them find the right fit)

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.

The Mythical Man Day — Another Fallacy of Software Development

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.

Brooks’ Law Continued — Ramp-up Step Function

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.

1. 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?
2. 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.
3. Functional level of team – The overall experience composition level of the team—including junior & senior engineers, leaders and domain experts.
4. 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.
5. # 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.
6. 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.

Brooks’ Law Continued — Team Ramp-up

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.