Performance Appraisal For An Agile Team

Our affection with Bell Curve has been for long. 
-It is (one of) the most "natural" scheme(s) of evaluating
and judging performance of an employee in an enterprise.
-It provides a fair view of the employee performance level
of all employees to the management.
-However, in an Agile world, where everyone in the team is expected
to exercise equal responsibility and accountability,
does Bell Curve PMS act as a hindrance?
-Does it motivate a few and demotivate others?
-Is it the right tool to use?
-Is it used in the right manner?
-Does it affect the performance of a highly productive and efficient team?
-Do we have a choice?
 
3 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

- Brief on the traditional system

- Short comings of the traditional system

- Introduction to Agile way to performance evaluation

- Preparing your team for this appraisal system

- Preparing management for the change

- Expected outcomes 

- How this system can be adotped by any organization - Ways and procedures

- Exercise

- Feedback from audience

Learning Outcome

* Understanding concerns of Agile Teams wrt Appraisal
* Brief look at the current performance appraisal system
* Understand how we can bring about small change in this system
* Share experience of adopting a more agile performance appraisal system 
* Share how team behaves and responds to the modified system of appraisal
* Share benefits and requisites of this modified system
* Run a small exercise for audience to be able to adopt similar system
* Learn from others

Target Audience

All

schedule Submitted 4 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Karthik Sirasanagandla
    By Karthik Sirasanagandla  ~  4 years ago
    reply Reply

    Hi Sharad, do you mind sharing some pain-points in the traditional appraisal system and how the said change in the system affected the team(s)? IMHO, it helps the readers of your abstract to better connect with your proposal. Thanks. --Karthik

    • Sharad Julka
      By Sharad Julka  ~  4 years ago
      reply Reply

      Hi Karthik, Thanks for feedback. I believe whatever I mentioned in the abstract got presented in one single line. I have put it in multiple lines now. Please let know if this solves your purpose.

      Regards, Sharad 

      • Karthik Sirasanagandla
        By Karthik Sirasanagandla  ~  4 years ago
        reply Reply

        I'm not getting to see what I asked for :( As a reader, when I read the abstract, I wish to picturise your thoughts on the topic that you propose. It would help me if I have some insight on your thoughts.

        Also, it would be cool if you can share link(s) to the presentation,blog, etc., if you've already presented it elsewhere. Thanks. --Karthik

        • Sharad Julka
          By Sharad Julka  ~  3 years ago
          reply Reply

          Question:What are the pain points of the current system(Bell Curve or any other)

          Answer:

          1. These are relative appraisal systems that measure people against people and not against targets. In a large organization, where projects can vary, their customers vary, the requirements and expectations vary, it is not just to measure everyone on same or similar scale. Even if we measure them across same or similar grades, we cannot rule out the fact that they might fall in different projects.

          2. Bell curve system specifically focusses on 20-70-10 principle which focuses on finding low performers but does not suggest any steps to help these 10% move from lower to average or above average level.

          3. Since this is relative, there is always a lower 10% that will come out. When this practice is forced upon, it leads to even relatively less performing individuals to fall in lower category. They might not be doing that bad. Using this practice over years leade to low morale of employees and high attrition.

          4. In agile methodology, where teams are given larger focus, Bell Curve does not fit.

          The methodology under proposal tends to provide a more agile way of exercising appraisals than any other traditional system. It has following benefits:

          1. It focuses on teams as well as individuals

          2. It provides early expectations and early feedback

          3. It follows agile principles, is in line with Agile Manifesto

          4. It requires everyone to play as important a role as other, i.e. teams are equally important when deciding on goals

          5. It is more absolute than other method(s), as it believes in achieving targets than comparing people

          Limitations of proposed method(Under consideration)

          1. The proposed method does not factor renumeration or compensation when doing appraisals. 

          2. It requires top-down approach, i.e. it cannot be implemented by individual business units in isolation in case effective implementation across organization is intended.


  • Liked Naresh Jain
    keyboard_arrow_down

    Naresh Jain - Scaling XP Practices inside your organization using Train-the-Trainer Model

    Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 4 years ago
    Sold Out!
    90 mins
    Workshop
    Advanced

    How do you effectively scale skill-based, quality training across your organization?

    Over the years, I've experimented with different ideas/models to scaling skill-based training across an organization. In the last 4 years, I've pretty much settled down on the following model. Its very useful when mentoring teams on skills like Test-Drive-Development (TDD), Behavior-Driven Development (BDD), Product Discovery, Writing User Stories, Evolutionary Design, Design Patterns, Problem Solving, etc. I've successfully implemented this model at some very prominent fortune 500 enterprises.

    The goal of this workshop is to explore what other successful models organized have used to scale skill-based training in their organization.

  • Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 4 years ago
    Sold Out!
    45 mins
    Demonstration
    Intermediate

    "Release Early, Release Often" is a proven mantra and many companies have taken this one step further by releasing products to real users with every commit a.k.a Continuous Deployment (CD).

    Over the years, I've built many web/infrastructure products, where we've effectively practiced CD. However at Edventure Labs, when we started building iPad games, we realized there was no easy was to practice CD, esp. given the fact that Apple review takes a few days.

    Our main question was: As mobile app developers, how should we architect/design our apps for CD?

    We were a young startup, learning new behavior about our users (kids aged 5-8) everyday. We could not afford any delay in releasing latest, greatest features to our users. To solve this problem, I believe we've built an innovative solution to enable any mobile app developer to achieve CD.

    If you are building real products, which have platform/3rd-party dependencies and you want to practice CD, this session is for you.

  • 45 mins
    Experience Report
    Intermediate

    Agile processes are the new order of IT implementations. These talk will elaborate on our experience and learnings during agile process implementation at Walmart. 

    We will touchupon following 3 key areas and our learnings that helped us scale agile in large enterprises.

    • Process Visualization - Our learnings related to visualization of existing processes and practices and how it helped us identify signals from noise

    • Product Backlog Elaboration - In a complex and large programs product backlog management and role of product owner needs to be revisited.

    • Team Working Agreement - This is particulary crucial for scaling agile as dependency management is one of the key aspects of enterpsie agile implementation.

    We will conclude with our key learning of how processes needs to be continuously evolved in large scale implementation.

  • 45 mins
    Demonstration
    Beginner

    Can you maintain agile engineering practices with a distributed team?

    Johannes is the Oslo based Chief Scientist for the Sri Lanka based company Exilesoft. In order to promote agile engineering practices, he uses remote pair programming to connect with teams halfway across the world.

    In this talk, we will go through a practical approach for remote pair programming adopted for high-latency situations. We will demonstrate remote pair programming with a live example and we will discuss the advantages and usages of the approach. We will also cover the practical parts of remote pair programming, such as tools and setup.

    After seeing this talk, the audience should be able to remotely pair with members of their distributed team. They will also get a lot of tips on how to use pair programming effectively in both local and remote settings.

  • Liked Jason Yip
    keyboard_arrow_down

    Jason Yip - Think Like an Agilist: Deliberate practice for Agile culture

    Jason Yip
    Jason Yip
    Principal Consultant
    ThoughtWorks
    schedule 4 years ago
    Sold Out!
    90 mins
    Workshop
    Intermediate

    If I say, culture is important to adopting Agile, most people will just agree without even thinking too much about it.  But what is meant by "culture"?  Why is it important?

    Culture is not typical behaviour; it is not what we say we value (but don't actually do).  Culture is our basic assumptions of how things work.  Culture is the logic we use to think through and respond to any particular situation.

    If you imagine a pyramid, Agile practice and any other visible behaviour is on the top, stated or written Agile values and principles are in the middle, fundamental assumptions (aka culture) is at the base.

    My session is intended to expose people to the base of that pyramid.

    If culture is assumptions, then to understand Agile culture, we need to understand the basic assumptions of Agile.  To do this, I have created an approach called "Think Like an Agilist" that both exposes how we think through an "Agile situation" and allows us to deliberately practice "Agile culture".

    The general idea is that I won't just talk about Agile culture and values, what I'll call "culture theatre", but rather expose people, who nominally consider themselves part of the Agile culture, to their underlying thought processes and assumptions, given a relatively difficult scenario.  Those thought processes and assumptions are the essence of culture (reference Edgar H. Schein).  What is interesting is noting when the thought processes and assumptions are different which indicates that there is a different culture at play.  What I've noticed is that this difference is common between novice vs expert Agilists.

    Note that it isn't even about analyzing vs doing it mechanically but more about exposing what assumptions are being used to respond.

    NOTE: I will be updating the attached slides as when I created them, I was framing it more as "doctrine" rather than "culture", defined as fundamental assumptions"

  • Aman King
    Aman King
    Agile Technologist
    ThoughtWorks
    schedule 4 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Are you an Agile Practitioner? Or are you responsible for Agile transformation?

    Organizations that have begun their Agile journey welcome the guidance of an experienced Agile Coach. But external guidance cannot continue indefinitely as the only way to scale Agile.

    If you are in an Agile team, are you prepared to take on the coaching role for other teams once your Agile Coach moves on?

    If you are a manager, are you looking at grooming in-house coaches to scale and self-sustain transformation?

    The transitioning of practitioners into coaches can be key to your Agile journey. Individuals get to build on their potential, while the organization becomes more self-reliant.

    This session explores my personal journey from practitioner to coach. It should help you too in taking that first jump into the role of a coach. I will share real-world examples of dealing with on-the-fly situations, and of preparing upfront where possible. I will recommend resources, and mention handy techniques that should be in a coach's toolkit. The session essentially provides a kick-start for first-time coaches.

  • Liked Nikhil Joshi
    keyboard_arrow_down

    Nikhil Joshi - Build - Measure - Learn : Without spending a fortune

    20 mins
    Experience Report
    Beginner

    At times we have great product ideas but the biggest barrier to entry lies in answering few questions such as:

    - How do I define and validate Problem hypothesis, Solution hypothesis and Underlying assumptions?

    - How do I quickly setup a platform for people to register their interest?

    - What will keep the potential customers engaged, excited until the first release (or beta) is out?

    - How do I get feedback from the early adopters?

    - And eventually when I have answers to some of these questions, how do I make a decision to persevere or pivot?

    If you've faced a challenge while answering any of these questions while building/validating your product idea, this session is for you. We'll look at tools and techniques to validate the product hypothesis early-on without spending months or fortunes. We'll also look at a case study to highlight how some of these tools, techniques helped us validate our product idea.

  • Liked Neil Killick
    keyboard_arrow_down

    Neil Killick - The Guessing Game - Alternatives to Agile Estimation

    Neil Killick
    Neil Killick
    Lead Agile Coach
    MYOB
    schedule 4 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Agile promotes empiricism and change, yet many practitioners continue to scope out and estimate delivery times and costs for software products and projects.

    Defenders of the art of estimation claim that we need to estimate software projects in order to answer common business and customer questions such as:

    • Should we go ahead with this project? (go/no-go)
    • How much will it cost? (bottom line)
    • When will it be done? (predictability)
    • Should we do project B instead of A? (prioritisation)

    This session challenges participants to flip these questions on their heads and seek alternatives to estimation rituals. It covers the many risks inherent with an estimation culture and demonstrates real, practical alternatives, both at the portfolio and the sprint level.

  • Liked Savita Pahuja
    keyboard_arrow_down

    Savita Pahuja - Battlefield Agility

    Savita Pahuja
    Savita Pahuja
    Agile Consultant
    Palo-IT
    schedule 4 years ago
    Sold Out!
    45 mins
    Workshop
    Intermediate

    Battlefield Agility® is a quest to make our deliveries better, more collaborative, faster and effective. It relies on age old principle from the Army to provide a holistic view of the problem landscape which a project team needs to solve and be able to succeed in this, through small collaborative groups working in coordination to achieve the bigger goals.

    Battlefield Agility® derives from the Agile manifesto and principles and adds to it the key ingredient of individual wisdom to create a plan for a team which will help it succeed in successful deliveries . This is a goal based approach to increase MVP and ROI.

    The purpose of this method is to make team members more focused about their work, equal distribution of work in the team and increase productivity.

    Battlefield Agility enumerates the mechanisms of planning, better field view to all team members, ease of multitasking, reduce task switching.

    Key benefits of Battlefield Agility® 

    • A focused approach to software development as development proceeds through small battles to be won
    • Reduced multitasking and better efficiency of team members
    • Faster deliveries as the work is divided to right sized battles to be won
    • Parallel efforts by team members ensure the time to market is significantly lesser
    • Less process overhead as the collaboration is real time and more time is spent on the ground than on meetings
    • Small teams ensure close camaraderie and collaboration among team member
    • The team can even work on disparate work areas ( if required) in order to make best us of their expertise

     

  • Liked Ted Tencza
    keyboard_arrow_down

    Ted Tencza - Creating a Great Engineering Culture in an Agile workplace.

    Ted Tencza
    Ted Tencza
    Director of Engineering
    Bigcommerce
    schedule 4 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Company culture, or its DNA, is one of the most important factors to determing if a company succeeds.  Many companies claim to have great company culture.  But what does this mean, how can you know if your company has a great culture, and how can you go about improving the culture?  This talk will explore what great companies have in common, and share experiences I have had in helping to develop engineering culture during my career.    

    Will also explore how Agile principles help to foster creating the best possible culture for your organization.

  • Liked Ankush Sabharwal
    keyboard_arrow_down

    Ankush Sabharwal - Step-by-Step Process for Release Planning and Release Level Retrospectives

    45 mins
    Tutorial
    Intermediate

    In the session two processes will be explained viz. Release Planning and the Release Level Retro. Step by Step approach will be discussed so that the same can be readily used in your Agile Projects.

    I have created these approaches of conducting effective Release Planning and Release Retrospectives in Agile projects. I have used these processes in various successful Agile projects.

     

    Note: Please refer to the Links section below to see the steps invoved in both of these processes.

  • Liked Sharad Julka
    keyboard_arrow_down

    Sharad Julka - Agile For Open Source

    45 mins
    Talk
    Intermediate

    -Open Source development depends a lot on community, their feedback,

    their suggestions, their reviews and their enthusiasm.

    -For an open source development project, the community itself is the first customer.

    -Product release for the community provides a good starting point to assess

    how the product will be accepted in the market.

    -This is very beneficial as it gives the software development team an edge over

    its competitors as it gets the pulse of the customer

    -In many ways the open source development has the culture similar to that of

    an Agile enterprise.

    -The principles guiding open source development are similar to Agile principles

    -The session presents views on above as well as how open source development projects employ agile for

    both the community development and for their own licensed version of the software.

  • Liked Anand Bagmar
    keyboard_arrow_down

    Anand Bagmar - Build the "right" regression suite using Behavior Driven Testing (BDT)

    Anand Bagmar
    Anand Bagmar
    Director - Quality
    Vuclip Inc.
    schedule 4 years ago
    Sold Out!
    90 mins
    Workshop
    Intermediate

    BDT is a way to identify the correct scenarios to build a good and effective (manual & automation) regression suite that validates the Business Goals. We will learn about how this is different from BDD, and do some hands-on exercises in form of workshops to understand the concept better.