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 cause
unintended 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 score
Additional 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 Filled
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 System
Sprint #: 05
Sprint Dates: 9th March – 20th March 2015
Sprint Review Date: 20th March 2015 @ 3.00 pm
Feedback 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? 85
Was the time frame commitment met? 100
Is the UI intuitive, professional and pleasing? 85

Product Owner Report Card to Development Team
FROM: Product Owner TO: Team
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
Sprint #: 05
Sprint Review Date: : 20th March 2015 @ 4.30 pm
Team's "mojo" (teamwork, collaboration, helpfulness) 100
Team's ability to deliver to their commitment 95
Team's overall technical abilities 95
Team's ability to react to changes 95
Team'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
Sprint #: 05
Availability to team
Understanding of customer requirements
Product Backlog organization, prioritization, and maintenance
Speed of answers to team
Leadership skills

Scrum Master Report Card – Development Team to SM
FROM: Team Member TO: SM
Overall customer satisfaction scoreAdditional comments: 88
Sprint #: 05
Ownership of impediments 90
Ability to solve impediments 90
Coaching Skills 90
Knowledge of Agile / Scrum methods 90
Ability 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
Sprint #: 05
Feedback date: 20th March 2015
Collaboration skills 70
Helpfulness to rest of team 60
Ownership of the team's deliverables 70
Technical expertize 80
Ability 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?
 “Should we use velocity to help gauge how much to choose in a sprint
 “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
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
Date of the Project Completion: 1st June 2015
Feedback Provided by: Simon Reed – Chief Marketing Officer
Level of collaboration experienced with Product Owner
and development team 95
Team’s ability to react to changes? 90
Timeliness of the project? 95
Quantity of features delivered? 95
Quality 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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (9)

Ähnlich wie Individual peformance in a team game

Ähnlich wie Individual peformance in a team game (20)

Mehr von India Scrum Enthusiasts Community

Mehr von India Scrum Enthusiasts Community (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Individual peformance in a team game