Thoughts on Individual Measurement in Agile Development

Jeff: We talked in an earlier post, The People Part of People, Process and Tools in Agile Development, about the difficulties of measuring people. This is a real issue as Agile scales up and becomes more mainstream. HR concerns, such as individual career paths and growth in capacity in Agile development projects, have becomes more prevalent. Agile really started with small teams on small, pilot projects. This is a new problem in Agile.

Bill: Is this problem because Agile was initially done for small projects and now it is being used for much more. Or is the problem that is especially acute because Agile focuses more on people issues than traditional software development methods.

Jeff: Both. I think the people issues are more acute in Agile. Before Agile, we tended over the years to do things like rank ordering all the people in the organization through an evaluation process. We have known companies that have literally fired the bottom ten percent of people once a year.

Bill: Of course that encourages everyone to stab their neighbor in the back.

Jeff: Right. It has particularly bad consequences on Agile because Agile is a team sport. If you are always throwing out a person on the team there will be jockeying around this. So if Agile is a team sport how do we measure and help people with evaluation and growth?

To address this concern, we put together some guidelines on this for Agile that people have used. I do not claim to be an expert in this area. There are a lot of trials going on.

Here are the guidelines I recommend. For an individual I think about half of their evaluation should be based on how the team is doing. So we need some metrics on how the team is doing in terms of being an Agile team. We will talk about this in the another post but let’s assume that it is possible to implement.

Bill: So half of an individual’s performance measurement is based on the measurement of their team?

Jeff: Right. Now if you have lot of people in an organization that are not part of a team but just floating around, of course this does not work so well. We prefer when doing Agile to get people on teams and leave them there. The team dynamics are the difficult problem. The difficulty is not the coding, it is not the work people are doing. It is the team dynamics. In Agile we are suggesting that the team is the right unit to think about planning and execution, not the individual. Hence a team evaluation is an important component of an individual evaluation.

So let’s assume that you can evaluate teams. This leaves the other 50%. I think half of it (one quarter of the evaluation) should be on how that person is perceived by the team. So the team gets some say on how you are doing. Sometimes we see a situation where a team does not like working with a particular person. We have been in places where a team says we don’t want this person on our team. If we find a better place for that person a win-win situation occurs.

This indicates a level of team maturity that does not always exist. Teams need to know themselves and be able to talk openly to make such a conclusion. And, of course, it has to be handled well. But it is possible. Once, we took a team member off a team and its productivity instantly went up by 12% because this person was slowing the team down. His work was fine so I want to be clear that this was an issue of team dynamics not individual capacity. It does mean that you want to fire the person but they need to be on a different team.

The analogy I think you need to look at is the sports team and watching how people move around. Look at how some people work well in one team and not in another. This is a people issue.

Bill: I was about to mention sports earlier because in many sports situations, more so than business, the individual team member’s evaluation and their monetary rewards are based on team performance. Do they make the playoffs, etc. Someone is not considered a real MVP unless the team does well. We certainly experienced this in Boston when the Red Sox got rid of Manny Ramirez, one of the best hitters in baseball. The team did better because everyone on the team, except one, voted that he should go. Maybe they were being like a mature Agile team.

Jeff: Exactly. The team is trying to figure out how to be a better team. Team balance is very important. Sometimes the team needs a star to disrupt the balance and inspire them to do different things. Teams tend to know this more than we give them credit for. Managers think they know what is going on but the team often has better knowledge about this. Of course, good managers understand this.

So half of an individual’s evaluation is how the team does. A quarter of the evaluation is based on how the person is viewed by the team. 360˚ evaluations are a pretty classic way to do this.

This leaves the remaining 25 percent. Team member usually have an area of technical or functional focus. They might be in documentation or development. So we expect that this last 25 percent should be based on their growth in their functional areas. You can set goals for each person, such as learning a new computer language or a new technology. Some companies get pretty formal about this with classes and credit. Thus, the last 25 percent of an individual’s evaluation should be about their functional skills and if they get better.

Bill: I think one of the keys to success relates to something you said earlier. These measures cannot be comparative. You should not rank people based on the individual measures so it is not competitive. It takes out the competition. It has to be normative rather than competitive. Everyone can get an A if they deserve it.

Jeff: Exactly. Otherwise you cannot get a high performance team to engage in making the team succeed.

In looking at team dynamics, a lot of people have been exposed to Myers Briggs personality profiles. A lot of companies use this and many people know their ‘type’. Myers Briggs is very popular and the most widely known of these methods. Myers Briggs asks questions about how you are, how you function. If you are an introvert you tend to think before you speak. If you are an extrovert you tend to speak before you think. Teams that learn profiling such as Myers Briggs learn that different people function in different ways. Team members need to know this. As an example, if you have an introvert on a team you learn you must give them a chance to speak. If you make decisions at a team meeting too quickly it can inhibit the introverts from speaking.

Bill: There is the method of not letting any one speak twice until everyone speaks once.

Jeff: Yes, that does it.

In another method Kathy Kolbe is asking different questions. The main question she is asking is ‘what makes you want to do something?’ What motivates you to come to work? It refers to the will to act. Her classification includes things like starting new projects or being a follow through person. Do you like to complete things? Do like to be a fact finder? Do you like to have all the facts before you move on? Or do you like to make things beautiful?

Alaska Airlines uses the Kolbe method for their employees. On each employees badge there is a graph of their Kolbe metric. People use this. Kolbe suggests that better teams are balanced. We need some quick starts to ge going but if the team does not have any people who finish things the team will have difficulty completing anything. I have found Kolbe much more useful in making sure teams are balanced with the right mix of people to start and finish things.

The work Kathy Kolbe did came out of the skunk works projects from several years ago. The skunk works were a team concept that was developed at Lockheed as a better way to make planes. The U-2 and Sr-71 were both developed in this way. (They were very Agile!!!) Soon Skunk Works became very. In practice some worked and some did not. Kolbe looked at this. She discovered that a lot of these teams would get started quickly as they attracted a lot of quick starts but then no one on the team wanted to finish things. And they did not finish things. We would prefer our teams to finish things.

To summarize:
50% Team performance
25% Team evaluation
25% Individual growth in functional area
_________________________________________________
100% Individual evaluation

Comments

[128gb usb drive]

Among many advantages of agile development is the one which produces efficiency by squeezing away the cost of interaction between various members of a development team.This is achieved by getting rid of most the process around role interactions and encouraging informal interactions. Getting the problem solved is the primary focus, rather than role preservation, and hence efficiency improves many-fold.