Archive by Author

Scrum Gathering 2013- Karen Greaves: Agile Performance Appraisals Nobukhosi Dlamini

Karen Greaves: Agile Performance Appraisals – Do we need a number?

On the first day of the Scrum Gathering we kicked off with Karen Greaves presenting a talk on Performance Appraisals. As can be expected, the room was packed to capacity as many in the audience were eager to listen in and join the discussion on this thorny issue. After all, performance appraisals are that process we all love to hate. And with good reason too, many in the audience shared stories of negative experiences they have had with performance appraisals and there were only but a few positive experiences shared. The anxiety, discomfort and disappointment experienced around performance appraisals came both from those who were giving them as well as those who were receiving them. What was interesting to see were stats on how few CEO’s actually believed that performance appraisals were an accurate measure of individuals’ performance in their organization. Also, less than 50% of HR actually believe that performance appraisals in their current form are accurate.

Karen then shared her experience of how she felt about performance appraisals over the years in her career. When she started off working for Microsoft she had a very positive experience receiving an outstanding performance appraisal (and the relevant increase) for her hard work and effort. With that great motivation she maintained her hard work but the following year she received a lower rating much to her disappointment. When she did some investigation into why she might have received this low score, she was told that everyone gets a turn to have an outstanding rating, and she had already had her turn. Working at another company for a year and a half, she received neither a performance appraisal nor any increase. She didn’t mind the former, but was unhappy about the latter which led her to leave the employment of that company. In another company she had an outstanding employee whom she wanted to reward with the highest rating, however, her manager informed her that the company never awards that rating to anybody.

Karen explained how she was able to implement a fair performance appraisal system at Fundamo during the time when she was a development manager there. She explains that to do this she needed to gain support from her line manager as well as reach an agreement with HR. She was able to get both support from her manager as well as cooperation from HR by providing HR with the information they required. Her system started off with monthly 1-1 feedback sessions with each of her developers to continuously build the relationship and ensure that each person was always aware of how they were performing. This way no-one was ever surprised at the end of the year when they received their increase. She also eliminated the rating in the performance appraisal and made sure that the appraisal was delivered verbally, not through a letter.
However, HR required a number (as they always do), and she provided them with a number calculated based on each persons’ performance. She placed all her team members into one of three categories: the poor performers (which were very few), the average performers (which was the majority), and the superstars (which were also very few). However, this number was never disclosed to the team members as she felt it added nothing to the appraisal other than what she had already provided them with.

Based on that score, everyone was awarded their annual increase at the final appraisal. Although the final appraisal was nothing other than the monthly 1-1 meeting with the increase letter. In this way she managed to decouple the performance appraisal from the rating and increase based on a rating.

The discussion was interesting and thought provoking. The main thing that was highlighted is that there are some steps we can take to introduce changes in the performance appraisal process instead of suffering through them year after year. It requires some negotiations with the stakeholders, senior managers and HR being the main stakeholders. We can make changes by ensuring that we still provide the data that is essential in the HR process, but also reduce the pain and bureaucracy it has on our lives.

Written by: Nobukhosi Dlamini

Event Report: Agile Antipatterns

Karen and Sam from Growing Agile give us a runthrough on how antipatterns sneak in over time, often with the best of intentions with some examples:

WHAT: Burndowns updated by Scrum Master.
WHY: This antipattern features in many a team but if you do it, you own it. But who cares about the status the most? The team should, so it is best for them to own the burndown.
TRY: Don’t do it. Maybe the team will do it, it might even take 3 sprints, even longer..But the team need to fully understand their progress to do something about issues when they can fix it, rather then at the end when its too late.

WHAT:Same velocity every sprint.
WHY: Velocity should vary and should overall be going up.
TRY: Let the team know its ok to fail. Prepare management for failure. Commit honestly if you honestly believe you can do the work.

WHAT: Fines for being late to meetings.
WHY: You are giving people permission to be late.
TRY: When someone is late, don’t update them on whats happened in their absense, its their responsibility to find out what they missed after the meeting. Finish your meetings early to give people time to get to their next meeting. If people are continually late find out why.

We also discussed the difference between an antipattern and a problem. For instance a 45 minute standup is not an antipattern, its a problem.

For the remainder of the event we broke up into teams and discussed other antipatterns we found in our teams.

It was a thought-provoking evening and I really liked thinking about the differences between an antipattern and a problem. I also would use the format of WHAT/WHY/TRY again, its a good framework to use when thinking about issues.

Cape Town Event : Building self-organising teams with Information Radiators

When: 1 March 2012, 6:00PM

Topic: Building self-organising teams with Information Radiators.

Sign up: Please sign up here in order to help us with catering.

Venue: Allan Gray Portswood office in the Presentation Room on the third floor. You can download a map here. Everyone parking in the Portswood parking area will have to pay for their own parking tickets. There is also parking available in Beach Road.

Synopsis:

The self-organising team. The stuff of dreams, the dreams of team members and “management”. How do we throw off the shackles of accidental oppression and liberate teams to do their best work? David will share some of his insights from his experiences building and re-building teams. Key to great teams is communication, both internally and externally.

Information radiators are the things we stick on our walls and plaster on our development environments. We see them every day, they radiate information. The art of crafting an effective radiator is something that David has been trying his hand at for a while, and he’ll introduce his take on the core library and some friends.

Particularly interesting is how radiators can hurt or improve a team’s autonomy, innovation and quality. The tension that binds radiators and self organisation is expressed by Peter Drucker: “What gets measured, gets managed.” Let’s explore how we measure, who does it, and what do we really want?

David will be presenting on this topic at Agile Africa in May. This SUGSA sneak-peek will be the first time this talk has been presented, so please bring your critical thinking caps and add to the conversation.

About David Campey:

David’s credo: “Never waste a drop of talent”

about.me/campey

David started Information Logistics in 2004 and for the last 7 years has been uncovering better ways of developing software by doing it and helping others do it. David has built, run and led development teams from 2 – 30 people building products in companies from start-ups to some of the biggest companies in South Africa and the world.

David first tried out a task board and daily stand-ups with a large team in 2007, he has tumbled down the Agile rabbit hole. “Either the hole is very deep, or I am falling really slowly, for I’ve had plenty of time to look about and wonder what was going to happen next.” In his learning, the two main toolboxes David has drawn on are Scrum and Extreme Programming.

David still spends a large portion of his time at the code face, while balancing the processes of team creation at Information Logistics and finding cool new projects for the teams to work on.

Sponsored by

Unboxed Consulting