is considering a discussion about velocity as a performance measure and how to tell whether people are working hard
that started on the scrumdevelopment yahoo list.
Here's the original question, posted by Graeme Matthew
The unknown in all of this is that if a team have a velocity of 6 how do you tell if they should have a velocity of 8 i.e. they are underperforming. It gets complex. If they have a velocity of 16 are they doing well or have they estimated at the higher scale of story points.
0. Using velocity as a performance measure is wrong, wrong, wrong. Velocity just is, and you work to improve it over time by improving engineering practices, the work process, working relationships, and skills.
The assumption behind the questions is that people might be slacking off, not working as hard as they can.
I don’t want people to work as hard as they can. I want them to work hard, but at a pace where they aren’t making themselves more error prone, and aren’t exhausting themselves.
If the team seems to lack a sense of urgency, it might be because they are missing information about why the project is urgent. The fact that a senior manager made a bet on the golf course doesn't make the project urgent. That some sales person promised the moon and stars without any knowledge of the development effort is not urgent--for the development team. Making a once-a-year sales window...that's urgent.)
Some managers seem to want to know who is working hard, and how isn't.
My experience is that some people have to work harder to accomplish the same results that another person can accomplish easily. Some people look like the are working mighty hard, but are not accomplishing much.
Thinking that we have to have everyone working equally hard doesn’t make sense to me…Why would you want to punish the person who gets his work done quickly by piling more on?
Further, there’s almost always someone how isn’t the best programmer, but things just go better when he/she is on the team. They may not look like they are working hard, but take them off the team, and everyone's performance goes down.
Perhaps some different questions:
Are the conditions present for every member of the team to do his or her best?
Have the managers put together people with the mix of skills and expertise needed to do the work the company needs done?
Are individuals performing to the expectations of their pay level?
If there’s a perception that people are not working hard, what might the reasons for that be? (Systems, policies, procedures that dis-incent performance; work they don’t care for; disenchantment with direct managers?)
As a manager, I'm more interested in who is struggling and/or who doesn't have the skills or interest in doing the job they've been hired to do. In a manager-led team, that pretty easy to notice if you meeting with people on a regular basis.
On a self-organizing team, it's harder, but not impossible. First, there has to be enough trust to support transparency. When there's visibility into the work, then a manager can see where things are binding up, and investigate the source of the problem. The source might be a person, but might also be the process or some other factor.
Labels: agile, management