Question:
My organization is just starting to use Agile and the question regarding performance management and specifically how performance reviews were now going to be done for the employees. Everyone turned to the HR team for the answer so I’m doing some research on this.

It appears to be in the agile world some coaches and practitioners will say that “there should be no such thing as performance management” but I’m hoping people recognize that this is a reality in the corporate world and needs to be addressed. Currently our performance management system is based on an annual cycle and individual performance reviews/assessments are completed by the managers for their direct reports.

Can you share with me how organizations are addressing performance management and specifically performance reviews/assessments for individual employees that are on agile teams?

Answer:
This is a huge topic, worthy of at least a book, probably several. I’ll try to give some useful starting points based on my experience. I’ll start by saying that there is strong evidence that doing away with performance appraisals entirely might actually improve performance. Since you have said that the company isn’t ready to consider that option, I will focus on what to do within a traditional appraisal system when the company adopts agile practices..

As a starting point, nothing need change. People still have managers who are responsible for their performance reviews, same as it was pre-agile. I work with many companies that have been getting great benefit from adopting agile practices for years, without changing anything about the way performance appraisals are done.

As for possible improvements on the system, let’s assume for the rest of this piece that the organization in question is using a team-based agile methodology like scrum.

The simplest improvement is to use a 360 degree style appraisal, where the manager solicits feedback from an employee’s team-mates, product owner, and almost anyone else who works regularly with the individual. The one person I’d recommend leaving out of a scrum team member’s 360 review process is the scrum master. The scrum master role is designed to carry no position power, and even having input on a performance review might jeopardize the special relationship that scrum masters have with the members of the team.

Now let’s examine a slightly more progressive approach: team-level performance appraisal. Remember, scrum is a team-based approach to work. It allows management to treat the team as the working unit, as opposed to the individual. Teams make and keep commitments to the business. Teams deliver value. Thus, if we are going to measure performance, it is best done at a team level.

One of our large clients is doing a mixed approach to performance rating, where each team receives a performance score. The scores are based on a set of agreed upon metrics, including customer satisfaction with the team’s deliverables. Each individual’s performance score is a 50/50 mix of the team score combined with the manager’s score of the individual. This system allows managers to help employees develop professionally, while keeping people focused on maximizing the value delivered to the business by their team.

Cheers,

Chris Sims

Roy and Drew ask some excellent and hard questions, so tune in and give a listen!

Teams using this technique are typically able to estimate 20 to 60 stories in an hour. The game was invented by our friend and colleague, Steve Bockman. Here is how one team plays the game:

Team Estimation Game Part I: The Big Line-up

Frank, the team’s scrum master, has cleared space on a long section of wall in the team room, and now the team assembles in front of it. Brad, the product owner, has brought a stack of 30 user stories from his product backlog, and the team is going to size them by playing the Team Estimation Game.

“Kira, why don’t you go first?” Brad says, passing her the stack of story cards. Frank, who is holding a roll of blue painter’s tape, peels off a small piece and hands it to her.

Kira starts the game by taking the top story from the deck, reading it aloud, and taping it to the middle of the wall. Then she hands the deck off to Kai, who goes next.

Kai picks the next story off the top of the deck and reads it to everyone. “I think this one is bigger than the one Kira just placed,” Kai says, affixing his story to the right of Kira’s story.

Mark goes next. The story he reads strikes him as a small one, so he places it just to the left of the others.

Now Jeff picks a story off the pile. “This one is pretty small, too.” He hesitates, then moves Mark’s small story further to the left to make room for his. “But not as small as the one Mark just placed.”

The team continues to take turns placing stories. On Kira’s third turn, she doesn’t take a new story off the pile. Instead, she repositions one that is already on the wall, moving it further to the right. “Trust, me,” she says, “the legacy code for this one is a mess, and we are going to have to make it all thread-safe for this story to work!”

Soon enough, all of the stories have been placed on the wall—but the team continues to take turns. Now, instead of placing new stories, they are fine-tuning the order by moving them one at a time, sometimes silently, sometimes with a few words of explanation.

“Pass,” Malay says when his next turn comes, indicating that he is satisfied with the order of the stories. Justus passes during this round as well. Kira and Mark each move one more story, but pass on the next round. Eventually there is a round where they all pass. Part one of the Team Estimation Game is over!

The team now has their stories ordered left to right, smallest to largest. The story they all agree will require the least amount of work is farthest to the left, and the one that they believe will require the most amount of work is farthest to the right. What is remarkable is that the whole team has now achieved consensus agreement on the correctness of this ordering!

For those who have been paying close attention, you may have noticed that this game has the potential for an infinite loop. Mark might place a story to right, but then Kira could move it back to the left. Mark, in his next turn could move it to the right again, and so on forever. While the infinite case is theoretically possible, we have never encountered it the hundreds of times we have played the game.

Team Estimation Game Part II: What’s Your Number?

In preparation for round two of the Team Estimation Game, Frank produces a deck of Fibonacci cards. Each card in this deck has one of the Fibonacci numbers on it, from one to 144.

Mick starts off. He goes up to the wall and points to the leftmost story, vamping a bit like Vanna White on Wheel of Fortune. “This, ladies and gentlemen, is about the smallest story we are likely to see.” He tapes the Fibonacci card labeled “1” above the story.

Justus goes next. He holds up the card labeled “2” and considers the wall of stories, searching for the point where the stories on the wall start to be about twice as much work as the story with the “1” over it. He chooses his spot, and places the “2” card above a story that lies four cards in from the left.

Play continues for several rounds, with each team member placing a Fibonacci card above the row of stories where they believe a size break occurs.

When her next turn comes, Kira hesitates, then points to two stories. “You know,” she says. “I think we may want to reverse the order of these two. I think this one is an eight, and the other one is a 13.” She uses her turn to switch the order of the two story cards and hands the deck to Mark.

Mark places the “21” card above a story. Malay is next. He shakes his head, then removes the “21” card Mark just placed. “I think this is actually a 34,” he says, naming the next-highest number in the Fibonacci sequence. He replaces the “21” card with the “34” card.

“He’s right,” says Jeff.

Jeff helps Malay move the story cards just enough to create a blank space between the last size 13 story and the first size 34 story—when the team placed the story cards in round one; they left ample space between them to allow for this, knowing that things can shift during part two.

Malay tapes the “21” card above the blank space in the row of stories, to indicate that there are no stories of that size.

When everyone has reached the point where they feel confident enough in the sizes to pass on their turn, the game is over.

Now the team tidies up, moving the story cards to form columns under the Fibonacci cards. All the stories between the “1” and the “2” are collected in a single column under the “1” card; these are the one-point stories. The next column consists of all the two-point stories, and so on. The team never did put any stories under the “21, ” so that column remains empty.

What we’ve described is the simplest form of the game. When you play it on your team, note that you don’t have to start with a “1” as your smallest story size. If a player thinks there may be future stories that will be significantly smaller than the smallest story that is currently on the wall, they may opt to start with the “2” or “3” above the first story instead of the one. This leaves room for future stories to be sized smaller than the smallest story in the current set. For example, by placing a “2” over the leftmost, smallest story card, a player signals their belief that the team may encounter future stories that are half as much work to implement.

We teach this game to the teams we work with, and many of them tell us that they have never before started a project with the whole team believing that the estimates were correct. This is the way to build a plan that everyone actually believes in!

Excerpted from The Elements of Scrum, by Chris Sims & Hillary Louise Johnson.
©2011 Chris Sims, Hillary Louise Johnson and Agile Learning Labs. All rights reserved.

What, you say you don’t yet have a copy of The Elements of Scrum and are consumed with envy? Easily solved! Take one of our CSM or CSPO classes and you’ll get one, or if you just can’t wait, buy yourself a copy here on Amazon. Makes a great Mother’s Day gift! Just kidding. That would be, like, the worst Mother’s Day gift of all time. If you need a Mother’s Day gift, buy her a copy of my mom Ricki Grady’s book, BeBop Garden instead.

The most common thread in the video’s comments on YouTube seems to be about the bearded guy on the left. He seems to answer the question of whatever-happened-to-The-Captain, which still leaves unanswered the question of whatever-happened-to-and-Tennille.

The HBR research shows that the intelligence of individual contributors is not a predictor of a group’s intelligence. And that in fact a team dominated by a bossy, know-it-all individual contributor (yes, even one who actually does know it all), will be outperformed by a team consisting of lesser lights. But the most statistically significant predictor of higher team performance wasn’t the intelligence of the members of the team at all, but the presence of at least one woman on the team. Read the HBR interview with the study’s authors to learn how they designed the study, including how they measured individual and team “intelligence.”

Nasri goes on to talk about the tech industry’s gender gap, writing that “The latest Midas List, Forbes’ annual list of the 100 top venture capitalists, for example, includes just two women,” and that “only 8 percent of new startups backed by venture capital included at least one female founder.” It’s not clear what is cause and what is correlation in these numbers–I don’t believe male VCs are overtly biased against women founders, and I think that cultural factors other than bias can account for some of the disparity. For example, I am pretty sure there are more extroverts than introverts on those lists, too, which can also be explained by our unconscious preferences for certain presentation styles–”male” styles and “extrovert” styles of communication tend to be received more favorably on first impression.

As a person who is very concerned with language, I also wonder if our use of “team” terminology, deriving as it does from competitive sports, leads us to unconsciously favor masculine, extroverted team members and the funding of teams that resemble the 49ers more than those that resemble sewing bees. Gender manifests itself in subtle ways that go far beyond sex, into culture, communication style and unconscious preferences. Our collective favoring of masculine styles of team participation is something that is more about norms than it is about biases, for example.

In 2004, when I was editor of a newspaper, I wrote an article for Inc. Magazine describing how I used Home Comforts: The Art & Science of Keeping House by Cheryl Mendelson, rather than the ever-popular The Art of War as my management bible. Funnily enough, on re-reading the story, I find my “feminine” approach to management sounds pretty agile. I think the advice I gave then of looking to the laundry room as often as you look to the war room for management models holds very true today, and supports the HBR study authors’ conclusion that what made a difference in team success was including a diversity of thinking styles. What do you think?

We predict a fair bit of wrangling over just who is the customer and who the product owner on this particular project, but anticipate that development will flourish nonetheless. If we’re lucky, David and his wife Layla will supply us with lots and lots of adorable sprint demos along the way. Our compliments to the team!

Answer: On very large projects, it is common to have a high-level product manager setting the over-all direction for a product. That product manager might work with several teams, each of which might have their own product owner. Each product owner would maintain the backlog for their team. It might be true that the product manager is a bit more customer-facing and the product owner a bit more team-facing. That said, you don’t want the product owner to simply be a pass-through between the product manager and the team; what value would they be adding? Instead, you want the product owners to work closely with the product manager, customers, and the other product owners in order to understand and prioritize (order) the stories in their team’s product backlog in way that supports the overall direction and goals.

It sounds like your new product owner has the common misconception that all they have to do is capture requirements and then relay them to the team. If only it were that easy. In reality, it’s a lot of work to truly understand the needs of users and customers, as well as the needs of our own business. Once a product owner has this understanding, it’s also a lot of work to help the whole team share this understanding.

The product owner will have many conversations with the team about each user story. Some are informal one-on-one conversations. Some are formal conversations with the whole team, such as during the regular story time meetings (A.K.A. backlog grooming sessions). During these conversations the product owner, along with the other members of the scrum team, will craft and refine a set of acceptance criteria for each story. These acceptance criteria are pass/fail, testable conditions, that define what it means for the story to be successfully completed.

The product owner will want to see demonstrations of work in progress on a daily basis, so that they can provide guidance and feedback to help the team build something that best serves the users’ needs. The more frequently the team gets feedback, the easier it will be to make the needed adjustments.

Additionally, it is useful for the product owner to be a regular attendee at the team’s daily scrum. They don’t need to be there all the time, but the more often they can attend the better. At the daily scrum, team members share impediments that are impeding their progress. Often these impediments are questions that need answering before the team member can proceed, and often the product owner can answer these questions.

You might want to checkout our downloads page, and print out a copy of “What is a Scrum Product Owner?” as well as “As a Scrum Product Owner You…” handouts. Pass them on to your new product owner! Better yet (here come’s the totally self-serving bit), sign them up for one of our upcoming Certified Scrum Product Owner workshops.

Cheers,

Chris Sims

What if you are sending a team off to scrum training next week and want to give them a taste to fire them up? Or let’s say you are a scrum evangelist at your company and can only count on 15 minutes of your CEO’s attention to spark her interest? Or maybe you’re a scrum master and you just want your husband to learn enough about what you do that he doesn’t glaze over at the dinner table….

In those cases, you’ll need something not just refreshingly brief, but breathtakingly brief. Which is why we took some of the most salient material from The Elements of Scrum and retooled and repuropsed it into a pocket-sized, highly consumable little volume that is cute enough to send to your granny as a birthday card, but smart and sophisticated enough to slip to your CEO or HR director. Meet Scrum: A Breathtakingly Brief and Agile Introduction by Chris Sims & Hillary Louise Johnson. You can buy it on Amazon in paperback for $9.95, or get the Kindle version this very minute for a mere 99 cents.