Wednesday, February 29, 2012

Gaining first-hand insight into Employee progress within an Agile World

In the Agile world, some people find the performance review process a bit challenging and in some cases feel that it is unneeded.  Because we are moving from a more command-and-control environment to a team empowerment environment, a person acting in the manager role (e.g., functional manager, resource manager, etc) seems to have a harder time understanding what their employee is doing. Also, the manager needs to realize that when we move into an Agile world, discussion of performance should occur in a more collaborative manner with a focus on progress and learning.

Why does it appear harder? First, the employee is not (or should not be) taking work orders from the manager any longer and instead, the work should be driven from the product backlog (via the sprint backlog from sprint to sprint). Second, the manager actually does have less visibility into what the employee is doing since the employee should be 100% commited to their Agile Scrum team. So what should a reporting manager do? I’ve heard about conducting a 360 peer evaluation, but this is basically second-hand information. The question is, is there a way to gain first-hand information? What I recommend are the following ideas that can help a manager who has folks who report to him or her that are on an Agile (or Scrum) Team.

Let us start by considering the areas along the Agile process where a manager could gain direct insight into what the employee is doing. The two Scrum practices where a manager could listen into what their employee is doing is the Daily Stand-up and the End-of-Sprint Review.
  • During the Daily Stand-up (aka, Daily Scrum), the manager can quietly listen into the progress that the Scrum team members communicate during this brief meeting. Before you do this, contact the ScrumMaster and verify that this Daily Stand-up is an open meeting that you may quietly attend. If you do so, ensure you tell your employees that you may be sitting in on the Daily stand-up. If you have employees on multiple Scrum teams, you may not have time to sit in on all Daily Stand-ups. Instead of sitting in on random Daily-standups, a tip is to attend the same Daily Stand-up for 5 consecutive days so you get an idea of the work done by your employee for a weekly period (for continuity and consistency). Since the Daily Stand-up focuses on what the team member did yesterday, what they are planning to do today, and their risks, you will have some idea of how story and tasks are connected to the work of the employee and how well they are completing the work.
  • During the End-of-Sprint Review, you can potentially understand the employee’s progress by seeing what they demo (assuming the team members conduct the demo and not the Product Owner). If you learn that your employee is demonstrating work software during the sprint review, then you can quietly listen in to see what the employee built and how it works. Before you do this, contact the Product Owner and ScrumMaster to verify that you may quietly attend the meeting. If you do so, ensure you tell your employee that you may be sitting in on the End-of-Sprint Review for transparency.

You may notice that I emphasize “quietly” a couple of times. The key is that the Agile practices that I am talking about are not meant for the manager per se but for the purposes of building customer value and making progress through the project. The Daily Stand-up is specifically meant for the team members to communicate to each other on their progress. The End-of-Sprint Review is meant to gain valuable customer and Product Owner feedback so that we can ensure we are building the right product for our customers.

Next let us discuss other opportunities to gain employee insight  I suggest using 1:1s with employees to collaboratively discuss challenges, progress and learning needs but evolving it to become a continuous performance review.  These should be a low-key sessions that replaces the "big-bang" performance review.  During the continuous 1:1s, there should be an effort from both management and employee to be transparent and this should avoid any surprises when ratings or compensation matters are discussed. Ultimately, I would like to see the performance review process move away from the stogy and often negative intrustive event and evolve into a continous and collaborative discussion on progress and employee needs.  

What do you think of these ideas? Are there other ideas you have seen work successfully where a reporting manager can gain first-hand insight into their direct reports without obstructing the progress of an Agile project or the employee themselves?


  1. Those are good suggestions. I also suggest that managers periodically pair with their team members -- pair program, pair test, pair doc, pair whatever. Also, hang out in the team room and sit in on the retrospectives and design sessions.

    But more generally, get to know your team. Have 1-on-1s, of course. Just ask the employee what's going on. You can also follow them on Twitter and if they friend you on FB, pay attention to what they say. Play games with them and join them for lunch.

  2. @Andrew, yes these are good suggestions. Thanks for sharing!

  3. Hello Mario, May I know, how you do features estimation and how to relate with the cost management. How you monitor or control the cost?/

  4. Feels like more micro managing to me. You have velocity which determine how much a time can produce per sprint. You are trying to judge an individual and in agile it is the team that matters. You will not have everyone at the same level of expertize and knowledge and that is ok.

    Some people have for instance skills you cannot measure like interpersonal skills, others are great communicators, others have an amazing sense at detecting issue, others are the glue of your team by their mere presence they make everyone happy to be working. As a manager

    I view the performance of my team as a whole, I play the part of a facilitator helping them produce and have a stress free, office politic free environment. I provide for my team so that they do what is required so that we meet our objectives.

    It is better to become part of the team instead of above so as to share their issue and problems and help better. When you do that, if a team member is not anymone up to par, you will know quickly and more importantly why because you are part of the team, not above them so to speak.

    Remember that in Agile, you better have the team participate in the recruitment, your team will know if a newcomer will fit in and have what it takes to join in.


  5. Hi,

    I agree with Zak, great comments.
    In addition I like to add that you can get feedback in many ways on your team and individual performences.
    Are there communities active? Who is contributing? Any coding dojo's? Who come up with ideas, who is organizing? Which team or indivduals come up with improvements? Who is sharing and how?
    Who is experimenting with new tools or technics? Who is challenging the status quo? And there are many more ways.
    Key is that you spend time with the teams, as stated in earlier comments, attend meetings, work together, coach individuals and teams, etc.
    We try to spend half of our time with our MIP's (most importend people), => our teams and staff.

    As managers we have dealy Scrum of scrums with our scrummasters, daily MT standup where we discuss the impediments where the teams need help, but we also have our retrospectives on how we are performing and acting as servant leaders.
    With all this on a dealy basis you have automatic a good view a out what is going on!

    Regards, Paul