How to Choose People for a Team
Joe Little
Owner, LeanAgileTraining.com, Kitty Hawk Consulting, Agile Coach & Trainer, MBA, CST (Certified Scrum Trainer)
Sorry about the awkward title. I wanted to keep it short. The meaning is: How do we choose members for a new Scrum Team?
Introduction
There are many important questions as you start a new Team. This (getting the right people) is definitely one of them.
Let's assume you have a Mission or a Vision of the new product (or the work).
Let's assume that is decent, and at least should be motivating to the right people.
So, at least the thinking is: now we have to choose the team members. Again, I am assuming a Scrum Team of 7 people. (A fairly important assumption.)
3 Choices
Some say there are essentially three choices how.
A. The Manager or Managers choose the Team
B. The "pool" of people chooses the Team
C. Some combination of A and B.
Let's discuss.
The managers choose
Well, I already changed it, some. Not one manager but three.
Why? I think understanding people well is hard. And, with a Team especially, choosing correctly is important.
I recommend you gather three managers who know (a) the product (or the work) and (b) the pool of people available and the strengths and weaknesses of them all.
I recommend that the agile advocate (maybe the ScrumMaster, maybe the agile coach) explains to the managers what the roles are (in Scrum) and what we need in these people. And why.
Some considerations
I recommend (normally) that your Team is 7 people. We are assuming an important product, the next most important thing to work on, and getting it finished (or at least the first release) and out there quickly is very useful. For many reasons. Hence, never less than 7 people. (Hire if you must.)
I recommend that the PO is full-time and the SM is full-time. Why? Because it is worth it. (Yes, a subject for two later blog pieces.)
A good PO (with enough time) can make so much difference on the value and/or the speed of delivery. A good SM (with enough time) can make a huge difference on the productivity of the Team (if the firm enables impediments to be fixed) and on the quality of the product.
Also, I recommend that all 7 people are fully dedicated to one Team. If you were the Michigan football coach (they just won the championship Jan. 8 this year), at least during the season, would you allow a team member to be on another Team (eg, another sport in that same season)? It is not a viable question. (Again, not dealing with special cases now.)
The next evaluation is skill sets. We say "skill sets" quickly, but what we mean is complex. Personality traits, and a wide variety of abilities and knowledge. We won't make a list now.
So, you identify what you need for this product or work. Then you try to identify what you have, in the people you are selecting.
And, in a simple view, you first want as close to 100% coverage as you can get.
领英推荐
But it's more complex. Some "skill sets" are used a lot and many less frequently. So, from the 7 people, you want a skill set covered. And for the ones you need a lot, you want "deep depth" (as Yogi Berra said). For those of you familiar with sports, this is similar to a depth chart. Who is the starter at Left Tackle, who is second string, who is third string. A similar idea.
What you ideally want is: whatever is the next most important thing to do now - we can do it this sprint. Rather than say: "well, our one java programmer is full this sprint - we can't do that next java story until next sprint."
Gap Analysis and Remediation
After you review (a) what you need vs (b) what you have, you will inevitably notice gaps. Or at least relative weaknesses.
Then, first the managers must identify how we will fill the gaps. Here's a quick list of possible ways to fill the gaps:
(A bit later, the Team itself should identify the gaps (mostly better than the managers, I think is likely) and also discuss how to fill the gaps.)
Quick Final Evaluation
Two big questions we have not dealt with, that must be handled, although usually quickly.
The Team Chooses
One version of having the Team choose (or the group choose) goes like this.
You create and make available a definition of the work.
You let the people discuss the work and who should be part of that Team over a few days, perhaps over several lunches. (This probably means they'll spend more time thinking about all the variables than the managers will.)
The group proposes each Team, and the managers get a final say, yes or no.
Combination
One scenario for this is, the managers propose a team (and maybe several teams and several products at the same time). The managers have considered all the things mentioned above and more.
Then they somehow explain the work, show their choices for the Team (or each Team), and perhaps explain a bit their reasoning behind the choices.
Then the pool or group has a few days to modify what the managers defined for the Team(s).
This combination approach enables the group of people to think of things that the managers did not know, and optimize (we hope) the choices a bit more. For example, often the workers understand the work better, or the skill sets, or the chemistry, or just personal preferences (aka motivation) - in ways that the managers do not.
Hence, the experience is that commonly you get a better decision.
Conclusion
To summarize: