• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Agile Buddha

Demystifying Agile, Getting to its Core

  • Our Blog – Agile Buddha
  • Agile Workshops and Certifications
  • Agile Commune – Join Here!
  • Webinars
  • Contact
  • About Us
  • Show Search
Hide Search

Appraisals in an Agile Company – Part 1

by Avienaash Shiralige 4 Comments

Appraisals! How many of you dread this word? This is the only time in the year that you get to bargain for salary increments, everyone end-up negotiating to their best. Appraisals are closely connected with salary raise/increments, bonus payouts and it’s feedback intent takes the backseat.

Performance Appraisal

There are three major issues with traditional approach to appraisal:

  1. Measuring and rewarding individual behaviors and contributions OVER team based measurements.
  2. Long appraisal cycle(mostly once a year) discussing both salary increments and feedback.
  3. Feedback process – Filling long appraisals forms with least discussions between reviewers about reviewee.

For now let’s focus on the first problem. Let’s discuss about rest two points in the upcoming posts.

We all agree that agile team/organizations rely on team behaviors Over individual behaviors. But very traditional appraisal approach does not supporting this thinking.

One of the approach teams can take is to break performance measures into two parts.

  1. Team Measures : with X%(say 50%) weight-age. These measures are common to all the team members
  2. Individual Measures : with Y%(say 50%) weight age. These measures are specific to each team member

Note: 50% weight-age for team measures is the least I would advise to go for.

Under team measure, a balanced score approach can be taken to measure team performance. Some of the measures can be:

1. Client happiness – X% (say 20%) weight-age – Feedback collected from product management and stakeholders

2. Team financial contribution – Y% (say 10%) weight-age. If budget/cost are managed by the team, it empowers them on financial decision making too

3. Process followed to build the product – Z% (say 20%) weight-age.  Define few business, process and quality metrics in tune with organization maturity.

Note: Most metrics likely should come and go when the indicators they provide are no longer valuable as org gets more matured. So be careful about what you measure. Please find my earlier post on what to measure – Metrics to Build Great Agile Teams

Individual measures, can have following categories:

  1. Self development goals set-up by the individual in consultation with peers/SM/Manager – say 10% weight-age
  2. Organization and community contribution(outside of project) – say 10% weight-age
  3. 360 deg feedback – 30% weight-age

Weight-age given to each measure is something you need to figure out as per the organization agile maturity, culture etc.

Good luck with your appraisals! Sometimes I wonder – can we remove appraisals all together 🙂

Agile, Scrum Agile Teams, Appraisals, Metrics

Reader Interactions

Comments

  1. Charles Bradley says

    at

    Your approach is probably better than a traditional approach, but my preferred technique is something more like this:
    http://www.scruminc.com/agile-performance-reviews/

    Reply
  2. Anand says

    at

    Hello Avienaash,

    That is an excellent post. In order to become a truly Agile company, organizations will have to move towards Agile Appraisals, only Agile product developments won’t do.

    On these same lines, we have developed an add-on for Atlassian JIRA – UpRaise.
    https://marketplace.atlassian.com/plugins/amoeboids-upraise
    It is a complete employee performance management system, the agile way and within the comforts of JIRA.

    Reply
    • Avienaash Shiralige says

      at

      Agree. I will take a look at the tool. Thanks.

      Reply

Trackbacks

  1. Appraisals in an Agile Company - Continous Feedback says:
    at

    […] our last post, we discussed about how to break performance measures into team and individual measures to bring more team behavior orientations into […]

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

LikeBox

Tags

5 Whys Acceptance Criteria Adoption agile Agile Culture Agile Estimation Agile Offshore Agile Teams agile testing Agile Thinking Agile Transformation Agility Appraisals ATDD Automation Backlog Grooming BDD Big Picture business analyst Capacity Planning case-study code quality Collaboration Daily Scrum DevOps distributed agile Distributed Scrum Estimation Good Practices kanban kanban-mythbusters lean Metrics Planning Poker Prioritisation product owner Scrum ScrumMaster Sprint Sprint Demo Sprint Retrospective Story Point Story Points Sustainable Pace User Story

Categories

  • Agile
  • Agile Leadership
  • Agile Testing
  • Agile Transformation
  • ATDD
  • BDD
  • Continuous Inspection
  • Culture
  • DevOps
  • Distributed Agile
  • Estimation
  • In Conversation with Tim Ottinger
  • Java
  • Jira
  • Kanban
  • Lean
  • noprojects
  • Patterns
  • Presentation
  • Product Owner
  • Scaled Agile
  • Scrum
  • Software Metrics
  • Testing
  • Testing Practices
  • User Story

Copyright © 2025 · Malonus Consulting LLP

  • Email
  • LinkedIn
  • Twitter
  • Facebook
  • Privacy Policy