Individual peformance in a team game

Individual Performance in a Team Game

Regional Scrum Gathering 2015

5th June 2015

Where did this all begin?

2 © QAI India Limited. All rights reserved.

On my recent trip to China, I was asked a question, that I most frequently hear and that 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.

For the starter’s


Performance reviews and compensation questions are frequently on the front seat in every organization, so it should be no different in an agile oriented organization

It is possibly one of the most deeply rooted problem to get rid of when working with agile teams.

Traditional Projects

Performance Evaluation:• Innate intellectual ability• Subject matter expertise• Individual performance ratings• Ratings against others!

People Emphasis:• Subject matter expertise (SME)• Heroics• “Individual Contributor” roles• Individual training needs

Agile Projects

Performance Evaluation:• Innate intellectual ability• Subject matter expertise• Individual performance ratings• Ratings against others!

People Emphasis:• Generalizing specialists• Collaboration skills• Customer focus• Teamwork – mentoring, helpfulness,

approachability, personality, etc.

Measurements / Behaviours

“Tell me how you will measure me and I will tell you how I will behave.”– Eliyahu Goldratt

Hawthorne Effect – that which is measured will improve.

Measurements / Behaviours

Measurements dictate behaviour.

Measuring the wrong things can causeunintended consequences!

Outside View


A Scrum Master recently asked me if he should take over responsibility for year-end performance evaluations since he was closer to the work than the functional manager for the team.

One need to understand that Scrum Masters are in service to the team; they don’t manage the team

Outside View


“But,” you may say, “the Scrum Master is closest to the day-to-day performance of people on the team.”

That’s true. So, by all means give feedback on day-to-day performance and patterns of behaviour.

Provide clear, specific information about what you observe. Help people understand the impact their behaviour and work

results have on the team. This information that will help team members make choices to

continually improve their skills, professionalism, and contribution to the team.

By all means, coach people as they learn new skills. Help the team learn to self-organize by holding up a mirror on their

processes and challenge them to think and decide on their own.

Outside View


When the Scrum Master and the team are committed to giving each other congruent feedback, there’s no need for a performance evaluation: people know how they are doing and are working to improve every day.

What can you do if, as a Scrum Master, you are pressured to provide input for a performance review? Explain that you have been giving feedback throughout the year (or quarter). Give examples of how you have provided feedback and seen changes day-to-day (without naming names).

Explain that the work is interdependent, so it’s impossible to pull apart individual contribution. You are focusing on improving the performance of the team and that individual performance evaluation will detract from that focus

But we Live in a Real world that has different rules …


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, but 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.

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.



Managers believe they must engage in the ritual of annual evaluation—because they’ve always done it.

HR may have targets for percentage of reviews completed. Neither has a thing to do with actually improving performance.

Individual performance evaluations and annual reviews are an impediment. Steer clear of them—they are a vestige of command and control that Scrum can do without.


Agile practices and values put the emphasis on collaboration and communication. The performance appraisal creates an agenda divide as the employee uses it to try to highlight his or her performance in order to get raises and promotions.

This agenda can be a motivation for conscious or subconscious distortion of the data, or to behaviours that ultimately benefit the person doing them, but not the company or customer.

The appraisal fosters low trust competition in the team rather than self-organizing to meet customer needs.


VS.

Remembering Dr. Deming and his teaching’s …


Remove barriers that rob people in management and in engineering of their right to pride in workmanship. This means inter alia, abolishment of the annual or merit rating and of management by objective, management by the numbers

Personal review systems, or evaluation of performance, merit rating, annual review, or annual appraisal, by whatever name, for people in management, the effects of which are devastating.



Deming, wrote that un-measurable damage is created by ranking people, merit systems, and incentive pay.

Deming believed that every business is a system and the performance of individuals is largely the result of the way the system operates.

In his view, the system causes 80% of the problems in a business, and the system is management’s responsibility.

He wrote that using exhortations and incentives to get individuals to solve management problems simply doesn’t work.



Deming opposed ranking because it destroys pride in workmanship, and merit raises because they address the symptoms, rather than the causes, of problems.

It’s a bit difficult to take Deming at face value on this; after all, companies have been using merit pay systems for decades, and their use is increasing.

Moreover Deming was mainly involved in manufacturing, so possibly his thinking does not apply directly to knowledge work like software development.

Still, someone as wise as Deming is not to be ignored, so let’s take a deeper look into employee evaluation and reward systems, and explore what causes them to become dysfunctional.

Organizational Dysfunctions

Agile organization with Traditional measurements:• Rewards the wrong behaviours

• Creates/exacerbates the chasm

• Individual stature

• Promote myself

• Me first, team second

• Me versus everyone else

• Desire to become an SME

Appraisals mapping to Agile manifesto and Principles

Creating Competition Vs. Collaboration Ranking systems are used as a basis for dismissing the lowest performers,

making them even more threatening. When team members are in competition with each other for their livelihood, teamwork quickly evaporates.

Competition between teams, rather than individuals, may seem like a good idea, but it can be equally damaging.

Appraisals mapping to Agile manifesto and Principles

Creating Idea of Impossibility • Financial incentives are powerful motivators, so

there is a chance that the Individual or the team might find a way to do the impossible.

• More likely case is that the promise of a bonus that was impossible to achieve would make the team cynical, and the team would be even less motivated to meet the deadline than before the incentive was offered.

• When people find management exhorting them to do what is clearly impossible rather than helping to make the task possible, they are likely to be insulted by the offer of a reward and give up without half trying.

Principle # 5

Build projects around motivated individuals. Give them the environment and support that they need and

trust them to get the job done

Creating Sub-Optimization

• Recently in a SW org, the management offered testers 100 bucks for every defect they could find in a product about to go into UAT release.

• It was thought this would encourage the testers to work harder, but the result was quite different.

• After all, the more problems the testers found, the more money they made.• When we optimize a part of a chain, we invariably sub-optimize overall

performance

Destroying Intrinsic Motivation

Once employees get used to receiving financial rewards for meeting goals, they begin to work for the rewards, not the intrinsic motivation that comes from doing a good job and helping their company be successful.

Many studies have shown that extrinsic rewards like grades and pay will, over time, destroy the intrinsic reward that comes from the work itself.

Lets be real and face practical emotions of real people


Techniques to Perform Performance Appraisals

for Agile team

Performance Review – Should be regular

• While most systems focus on the individual, most agile people feel that the team should be judged and rewarded if anybody is going to be judged and rewarded. • Managers are used to sitting down at the beginning of the year and

establishing some kind of performance goals for each employee.

• So, here's a tip that is perfectly workable: 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 that you have to establish goals that are higher level than the individual goals that you are used to.

• By giving each member of a team the same goal, you have just implemented a team goal.

Performance Review – Should be regular

Performance review of an Agile team should be done at a regular interval, rather than it be a once upon year event.

Review should be cross functional and cross section (see future slides)

Sprint Report Card – Customer to Agile Team

FROM: Customer TO: Team

Overall customer satisfaction scoreAdditional comments:<enter additional comments here>

<sum/4>

Project: < Name of the Project>Sprint #: < ## >Sprint Dates: < From and To Dates>Sprint Review Date: < >

Measurements Score (0 - 100) Value of delivery in terms of quantity, business value? Do committed Stories work as expected? Was the time frame commitment met? Is the UI intuitive, professional and pleasing?

Sprint Report Card – Sample FilledFROM: Customer TO: Team

Overall customer satisfaction scoreAdditional comments:• Background colour is not matching our company standards• Application crashed when more than 10 clickers were working together

90

Project: Clicker Software for Student Response SystemSprint #: 05Sprint Dates: 9th March – 20th March 2015Sprint Review Date: 20th March 2015 @ 3.00 pmFeedback Provided by: Simon Reed – Chief Marketing Officer

Measurements` Score (0 - 100) Value of delivery in terms of quantity, business value? 90 Do committed Stories work as expected? 85Was the time frame commitment met? 100Is the UI intuitive, professional and pleasing? 85

Product Owner Report Card to Development Team

FROM: Product Owner TO: Team

Overall customer satisfaction scoreAdditional comments:

I thought the team overall did pretty well on this project. The team had some members new to this area so it took them a while to get up to speed and contribute at a high technical level. Also there were a few times where I felt the team was not truly accepting ownership of the customer desires.

95

Project: Clicker Software for Student Response SystemSprint #: 05Sprint Dates: 9th March – 20th March 2015Sprint Review Date: : 20th March 2015 @ 4.30 pm

Measurements Score (0 - 100)Team's "mojo" (teamwork, collaboration, helpfulness) 100 Team's ability to deliver to their commitment 95Team's overall technical abilities 95Team's ability to react to changes 95Team's ownership of customer needs 90

Review of Product Owner by the Development Team

FROM: Team TO: Product Owner

Overall customer satisfaction scoreAdditional comments: XX


Measurements Score (0 - 100)Availability to teamUnderstanding of customer requirementsProduct Backlog organization, prioritization, and maintenanceSpeed of answers to teamLeadership skills

Scrum Master Report Card – Development Team to SM

FROM: Team Member TO: SM

Overall customer satisfaction scoreAdditional comments: 88


Measurements Score (0 - 100)Ownership of impediments 90Ability to solve impediments 90Coaching Skills 90Knowledge of Agile / Scrum methods 90Ability to effectively facilitate the team meetings 80

Team Member Peer Review Report Card

FROM: Jain Smith TO: Sam Dean


Does not communicate effectively his impediments & stalled progress. He has the potential to be really good due to his technical prowess, but he needs to understand the team concept better. Several times I was hoping for much stronger collaboration.

70

Project: Clicker Software for Student Response SystemSprint #: 05Sprint Dates: 9th March – 20th March 2015Feedback date: 20th March 2015

Measurements Score (0 - 100)Collaboration skills 70Helpfulness to rest of team 60Ownership of the team's deliverables 70Technical expertize 80Ability to meet the said commitments 70

A Word About: No End-Customer?

In some projects, the team does not have direct access to the end-customer. What can you do in this case?

• Proxy – internal person playing role of customer (BA, stakeholder, etc.)

• Product Owner – customer voice in Scrum team

• Agile Manager

• Others?

End of Sprint Diagnostics – That Could assist Reviews

Some “diagnostics” to definitely measure:*

• Customer opinion

- Using the Sprint Report Card as shown in the previous few slides

• User story points delivered

- For team velocity computation

• Flow-based attributes

- # of user stories that were ready to start at the sprint planning meeting

- # of user stories completed – Met the DoD or considered complete by PO

- # of user stories committed, but could not meet DoD – therefore considered pending

* Be careful – only measure meaningful easy-to-collect items.

A Word About: Velocity – Should we use it for Reviews?

“Should we measure velocity?” • Answer: Yes, Of course

“Should we use velocity for release planning?• Answer: Yes, Of course

“Should we use velocity to help gauge how much to choose in a sprint• Answer: Yes, Of course

“Should we use velocity for evaluating the team or an individual?• Answer: Definitely, A BIG NO

End of Sprint – These measures do make business sense

Avoid measuring: Individual velocity Sum of all task hours for a person

• Compared to 40 hours/week Number of tasks/person Accuracy of task estimates – Something like our old favourite effort variance Accuracy of story points estimates remember estimate is an estimate, it

cannot be accurate) What about team’s ability to hit their commitment?

Make it different and make it count • One manager in China said to me, "Scrum seems to hide the contributions of

individuals, and I can't judge them as well." • My first thought was "Well, what does that tell you?" No one on a scrum team knows

better how each person is doing than anyone 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 What I suggested: • Announce 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 ScrumMaster and product owner.

• 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.

Project Report Card

FROM: Customer TO: Team


Overall a great project & a great team! The high levels of communication & collaboration were quite refreshing to me considering my previous failed attempt with another company.

94

Project: Clicker Software for Student Response SystemDate of the Project Completion: 1st June 2015Feedback Provided by: Simon Reed – Chief Marketing Officer

Measurements Score (0 - 100) Level of collaboration experienced with Product Owner and development team 95 Team’s ability to react to changes? 90Timeliness of the project? 95Quantity of features delivered? 95Quality of features delivered? 95

If the Projects are too long spanning across years …

Some projects are very long (1+ year) due to quantity of functionality and/or complexity. What can you do in this case?

• Snapshot – collect the project report card 2 or 3 times / year• Timing – collect the project report card right before the annual review• Timing – collect the project report card at the end of each major release• Others?

Agile Annual Performance Review process

1-on-1 because of personal nature and team member likely worked multiple projects

Performed by Agile manager, director, etc.

• Gather and coalesce the report card data!• Average team score for all sprint report cards• Average team score for all project report card• Average team score for all PO project report card• Average scores from project peer reviews• Query key co-workers, POs, Scrum Masters

for additional insights on the person

Discuss what these measurements show

Agile Annual Performance Review process

• Identify how to improve the teams

• Identify training needed to make teams more cross-functional

• Honest and transparent discussion

• Both positive and constructive

Agile Performance Review process – A few thoughts

The Scrum framework doesn't prevent you from measuring whatever you want to measure. However, you'd be missing the spirit of Scrum if you measured the work of a single team member.

The fundamental point is that if a Scrum team member is not able to contribute, then this points to a team problem.

As with any new approach, introducing an Agile performance evaluation system will have its challenges: Resistance to change Fear – too revealing Deflates the general optimism Loss of control Cheese mover comfort zone, Etc ..

A very important part of any Agile rollout is to align the performance evaluation system (and other HR practices) with what Agile emphasizes

Final Thoughts in this journey Conclusion is that tracking an individual's performance constitutes crime in

the Scrum world. The fundamental idea of Scrum is team collaboration, and team members

"volunteer" for tasks rather than having them assigned. One of the core values of Scrum is courage, and it's not a bad practice to

announce at the daily stand-up, "I missed my task timeline today." If that's the case, the Scrum team collaboratively aligns itself to meet the sprint backlog, at least enough to result in a shippable product when the sprint ends.

The keys, then, are accurate sprint planning and a "must-do" sprint retrospective. Most important, don't wreck the Scrum by measuring an individual's work items.

It is human nature for people to modify their behaviours to match the evaluation system

Not doing so causes dysfunction that will erode the team’s effectiveness

Final Thoughts in this journey

Sprint report card Sprint - a few diagnostics to measure and a few not to Project report card Product Owner report card Project peer review Annual “Agile performance review”

Individual peformance in a team game

Leadership & Management

Transcript of Individual peformance in a team game