Featured Whitepapers
- Apples, Oranges, and Acorns - All Agile Development Tools Are Not the Same
- One's Enough for Agile Application Development Management
- Requirements Management 101 – 4 Basics Everyone Should Know
- Tips on Requirements Traceability – Learn How to Control Change and Improve Quality
- Scaling Continuous Integration to Large and Distributed Teams
|
Make no mistake – this is a big question for managers out there and there are no simple answers. I do have a few practical tips and thoughts to share on the subject. My purpose in this article is to give managers of Agile teams a few places from which to start developing their own approach to performance management for Agile people. It’s almost amusing that out of the entire universe of people practices[1] that are a part of managing a company, the ones that managers seem most concerned with are a very few:
So let’s take a look at why this is a difficult question and then toss away the theory in favor of imperfect but workable approaches that you can use next week. Performance Management Basics – Why It Doesn’t Work Why do we do performance appraisal? The authors suggest five different goals or functions that tend to be wrapped up in performance appraisal systems:
As Bas Vodde and Craig Larman discuss[2] and Michael James[3] points out, most HR professionals do not seem to be aware that modern research has shown that the most popular performance management systems in use today not only do not achieve the positive results for which they were supposedly designed, they actually tend to produce net negative results. These systems are in place because they seem like a good idea and everybody expects them to work and gosh, they sure seem common-sensical. Yet Tom Coens and Mary Jenkins say, “The widespread practice of using individual performance appraisals to attain organizational improvement stems from the myth that better organizational performance will result from getting each person to do a better job. Substantial organizational improvement can only be achieved by improving the whole organization as a complex system.” The authors show that current performance management systems do not do a good job on any of these functions, and they further suggest that as a start, companies should design separate systems for each of these functions if they want actual good results. I am not an HR professional, so I rely on the authors’ surveys of the literature when I (hopefully correctly) restate their conclusion that there is virtually no scientific data that supports the idea that performance appraisal as currently practiced by the vast majority of companies achieves any of the things that we all routinely believe it does. It’s interesting to me that W. Edwards Deming’s 14 Points, published in 1986[4], include the exhortation to “Eliminate Management by Objective” and " …abolishment of the annual or merit rating …”. Performance Appraisal – Satisfying Your Company and Doing the Right Thing Managers are required to determine who is performing better so they can be rewarded more than others who are judged to be doing not as well. Also, managers are required to do performance appraisals because that is what everybody at the company is required to do. It’s a tricky place to be, but there are some compromises and approaches that have been shown to work for many managers in this situation. Team Goals 1. Give all of the members of an Agile team the same performance goals When you do this, several things happen. First is that you find you have to establish goals that are higher level than the individual goals that you are used to. “Complete the design of the file system thingie and implement it” is a common form of individual performance goal for software developers. But if you are going to give goals to a team, they need to be in the form “Ship Frboz Release 1.0 in Q2”. That’s something a team does. By giving each member of a team the same goal, you have just implemented a team goal. The second thing that happens is that people feel more comfortable contributing to the team goals since they are also each individual’s goals. At review time, the review discussion will center on what a particular individual did to help a goal be achieved, which is kind of what you want, right? A side benefit of Scrum is that some team members will come to the review meeting with a list of every sprint task they owned in the past year. This is a level of detail that is not usually available to the waterfall manager or employee. Another consequence of this approach is that you have a way to deal with the tricky corner cases of a) a star performer on an unsuccessful team and b) a dud performer on a successful team. Many managers are not comfortable with rating someone highly just because her team has excelled, and those managers are even more uncomfortable rating a known and widely-acknowledged star poorly just because their team did poorly. In this approach, you can find that even though a team performed badly, a certain individual really contributed in a larger-than-life manner to the teams’ attempts to achieve its goals. So this approach can provide a stepping-stone toward complete team-based ratings. Individual Development Goals 2. Assign individual goals for individual development. 3. Make sure individual goals are aligned with team goals. Many traditional engineering goals for people are structured around owning a particular component or designing or implementing a component. These goals are inappropriate for an Agile team member because there is no room to redirect someone from contributing to the team’s goal of building value to a non-value-oriented goal of completing a component. A team member who is supposed to design and build a component will concentrate on the component and not on the feature that it supports. This monkey wrench can make the wheels of Agile production grind to a halt. So these kinds of goals should be avoided. It’s reasonable and helpful to desire that someone take the technical lead in implementing a user story or theme, on the other hand. 4. Frequent 360 degree performance feedback is better than many alternatives One manager in China said to me, “Scrum seems to hide the contributions of individuals and I can’t judge them as well.” (In my head my first thought was “Well, what does that tell you?”) Nobody on a scrum team knows better how each person is doing than everybody else on the team. Make use of that by trying 360 degree reviews. Doing them frequently takes away a lot of the sting and after a couple of rounds there will be no surprises left. Doing them outside the formal review process will allow people to comfortably give the kind of feedback that can really make a difference. Here’s how I did them. I announced to the team that we would do voluntary 360 degree reviews. Nobody was required to participate, but if you wanted feedback you had to give feedback for everybody else on the team, including the SM and PO. All feedback was handed in to the manager, who edited it together to make it impossible to determine who said what. Feedback was then delivered to each person directly and in private by the manager. Team Behaviors 5. Value highly the personal traits, characteristics, and behaviors of good team members. Compensation
It would take another article the size of this one or larger to properly discuss the foregoing assertions, so I won’t attempt to do so here. Suffice it to say that none of the assertions above is true. Minimize Compensation Differentials Would you say that $350 per month on top of a salary of around $8000 per month really makes a big difference? Given that a bonus can’t make you any smarter, what is the real incremental improvement that we expect to see after investing all of the time and effort into figuring out how to parcel out the available raise pool? Now let’s put that raise in context. Most people want desperately to get a raise that is bigger than the one that their colleagues got. It turns out that most people feel they deserve it because most of us think we’re better performers than our colleagues. So, if I get my net $350/month raise and my colleague gets $250, what is the effect? I will feel a little bit good for a short time after the raise is given. My colleagues who got less than me will feel bad, and for longer than I will feel good. How much simpler would it be to just pay people fairly, and eliminate the jealousy around inconsequential pay differentials. One reason people put so much weight onto such small differences is that they are looking for signs of recognition and appreciation. Give them the recognition and appreciation all of the time, throughout the year, and you will find that the need for a symbolic but inconsequential raise will shrink. Make the Outcome be Correct Emphasize the Non-monetary Satisfactions of Agile Deal With the Outliers Summary [1] “People practices” is an Agile way to name what are commonly called HR practices. I don’t know where it came from, but I long ago learned that Agile people prefer to be “people” instead of “human resources.” I long for a beer and a companion who wants to debate the question “Can you ever be Agile in a company that has an organization called “Human Resources”? [2] Craig Larman & Bas Vodde, “Scaling Lean and Agile Development”, Addison Wesley, 2009, pp. 267, 268. [3] “What HR Doesn’t Know about Scrum”, Michael James, Better Software, Jan, 2010. [4] Deming, W. Edwards (1986). Out of the Crisis., Chapter 3. MIT Press. About the Author Alan Atlas has been professionally involved in high tech for nearly thirty years. Starting out with a BA in Psychology from Brown University and a BSEE from the University of Massachusetts, he joined Bell Labs as a hardware engineer and promptly went off to Georgia Institute of Technology to get an MSEE. During his time at Bell Labs, he discovered software and taught himself the C programming language.
While a Sr. Development Manager in Web Services at Amazon.com, Alan discovered Scrum. He became a Certified Scrum Master and he and his team used Scrum for over a year to successfully deliver Amazon S3, the Codie-award-winning web service that provides unlimited Internet-connected storage. Alan became a Certified Scrum Trainer and the first fulltime Agile Trainer/Coach at Amazon. His experiences in this capacity led him to seek and achieve the Certified Scrum Coach designation, and then to make a career switch into fulltime Agile coaching and training at Rally Software. Alan has presented at Agile2009, the 2009 Munich Scrum Gathering, Agile China 2010. He has given certification courses in North America, Europe, and Asia. Outside of work, Alan plays tenor and baritone saxophone in Motown-style soul or rock bands, scuba dives, and naps whenever possible.
Set as favorite
Bookmark
Email this
Hits: 5599 Trackback(0)Comments (2)
|
| Last Updated on Monday, 31 January 2011 13:29 |
Agile Marketplace - Announcements and Special Offers
The Business Case for ALM Transformation
Are legacy systems holding your company back? Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper


On my recent trip to China, I was surprised that the question I was asked most frequently was “How do I do performance management for Agile teams?” I wasn’t surprised that this was a question, but it’s not usually the first one that comes up when people start to talk about making Agile work in their companies.
