My organization has been doing waterfall for many years, but we are dipping our toes in the agile pond currently. So far we have had a couple successful projects using agile so everyone is gung ho about it. However, upper management has some concerns about the lack of individual accountability.

In waterfall, it is very easy to see that there are tasks with due dates that are assigned to individuals that are either delivered on time or not. And this data is used in part for end-of-year reviews, bonuses, etc. Agile shifts the accountability away from the individual and toward the team. The team either delivers the stories for a given sprint, or they don't.

Management is having trouble figuring out how to get the individual performance metrics they want out of the agile process. They need a way to see which people on their staff are high performers and which aren't. But the only place where individual assignments are made in agile is a sticky note on a Scrum board, which doesn't have any upward visibility or historical tracking.

What are the techniques for tracking individual accountability when using agile? Will this level of tracking hurt the team mentality that agile seeks to create? How can we meet the needs of management of knowing the relative strength of their staff members, while still focusing on the team accountability with agile?

  • Interesting question, I am looking forward to see the answers. And I like your first sentence, nice water theme :)
    – Angeline
    Commented Aug 31, 2011 at 13:26
  • 1
    @angeline thanks. Let's pretend that was intentional cleverness. :-) Commented Aug 31, 2011 at 13:54
  • 2
    Perhaps upper management shouldn't be the ones handing out bonuses or doing reviews in the first place.
    – corsiKa
    Commented Sep 1, 2011 at 0:53
  • 1
    "They need a way to see which people on their staff are high performers and which aren't. " Why?
    – Ben
    Commented Sep 1, 2011 at 11:18
  • @Ben, like a lot of companies, everyone goes through yearly reviews where they get raises, bonuses, and new performance goals. A line manager only gets a certain amount of funds to hand around to his staff so he needs to know their relative strength in order to appropriately compensate. Commented Sep 2, 2011 at 10:11

9 Answers 9


Actually this is one of the reasons why we need managers in agile teams. The team's responsibility is to back up weaker members and deliver. It doesn't mean however that poor performers should have an easy life in agile teams. One thing is to get the job done, another is to tell who did heck lot of work and who was just standing on the side watching how work is being done by others.

Let the team do their work and manager do theirs. Actually if we discuss Scrum teams (this is my assumption here, as you don't state it explicitly) you probably have 7 +/- 2 people in any team. This means that manager, working full-time should easily be able to share reasonable feedback about any of the members any time. Considering managers have fewer other tasks, as the team deal with many of regular issues it should be even easier.

So the answer is: if you need to judge individual accountability ask the manager. They should know.

  • 1
    Excellent point, Pawel. The need for people managers doesn't go away with Agile, it just shifts their focus. Your people managers should be working with each team member, setting individual goals and objectives and measuring their success against that. You can combine that with the overall team metrics to create a comprehensive picture. Commented Aug 31, 2011 at 18:31
  • 3
    Pawel, I fundamentally disagree with the point "The team's responsibility is to cover weak members up and deliver." The team's job is to deliver the most business value in the least amount of time, and their responsibility is to take ownership of any problem that could inhibit that job, including weak team members. That said, the team might choose to resolve the situation through training or internal coaching/mentoring rather than bringing it to management's attention. That is not management's business until the team chooses to bring it to management. Commented Aug 31, 2011 at 22:53
  • 2
    @Eric, I fundamentally disagree with the point "the situation (...) is not management's business until the team chooses to bring it to management." :) Yes, the team can choose to coach a poor performer or bring the issue to the management or leave it as it is. But it doesn't mean the manager can't act in any way before the problem is raised by team members. Even in agile teams it is manager who set boundaries, and in vast majority of cases one of boundaries is who is and who isn't the part of the team. Commented Aug 31, 2011 at 23:23
  • Good point. I didn't mean to imply a hands off attitude, only to combat an "application of external force" mindset. Changing a team's composition without consultation with or pull from the team is one of those negative external forces. Collaborative problem solving with the team is a great boon and a positive use of the partnership that should exist. Commented Sep 1, 2011 at 0:14
  • +1 I was thinking the same thing. the manager or Scrum master should have a clear view on how the people in the team are doing.
    – Kennethvr
    Commented Sep 1, 2011 at 9:28

Effective agile development requires an environment in which an individual is safe to put the "we" before the "me". As such, the idea of "individual accountability" is capable of fundamentally breaking agile teams, preventing them from making the teaming transition from "Forming, norming, and storming" into "performing." As such, I typically encourage teams to have a reasonable 360 peer and stakeholder review process, but not for the results to be "used" in any way by management other than meaningful career guidance. Instead, teams should share a standard reward where everybody gets a (for instance) 4% increase instead of trying to sort the team into different levels.

This does, unfortunately, fly in the face of many performance-based reward systems and MOST corporate reward systems that currently exist, and requires a very careful balance between enlightened use of the information and punitive use of the information. It's complicated by the fact that people outside the team, even managers very close to the teams, are often unable to see the benefit offered by connectors, activators, and a number of other strengths (See StrengthsFinder home page). Unfortunately, members of the team are often unable to articulate these capabilities, and resort to "Things just go... well... better... when John's around."

Fortunately, mature agile teams are often self-policing, and non-contributing members of the team will often vote themselves out or be brought before management by the team itself, although this behavior takes time.

  • It is very hard (in fact, pointless) to try to separate out an individual's contribution in a collaborative team. Remember that the demand for governance is inverse to the trust in an organization. An agile team has to face down not only development fears, but organizational. Some supporting links for you: merit pay Performance without appraisal Get rid of performance reviews Commented Sep 9, 2011 at 4:14

Individual velocity is a dangerous measure. I worked on a team once in which the dev manager wanted to measure individual velocity. She intended to use this for raises, meaning she would both compensate those with the highest velocity AND look for consistency in each person's delivery rate. This was a disaster. Devs stopped pairing, they were less willing to help one another with issues, they didn't want to help BA's write stories, they didn't want to work on defects, etc. Basically, anything that would decrease their individual velocity.


There are a lot of good answers here, so rather than pile on, I thought I'd provide one that is razor focused on management's perspective.

Businesses are more successful to the extent that they make good decisions and effectively follow through on them to successful outcomes.

Agile teams are more successful to the extent that the people closest to the work (the team) make the decisions about how the work is going to be done, who is going to do what parts, and when it will mostly likely be completed (forecast).

Did you notice the conflict? Managers in pre-Agile organizations traditionally have the key decision making skills (measurement, analysis techniques, etc.) as well as follow through tools/skills (bonus control; sticking to good, but tough, staffing decisions; etc.). Teams may not have those tools/skills and yet Agile calls for the teams to make the decisions and turn them into positive outcomes.

During an Agile transformation, managers have the right and responsibility to insist that important decisions continue being well made but the more decisions you can transfer to the folks closest to the work, the better. For decisions being transfered to the team, the team needs to understand the business' perspective on the relative value of comparison criteria for each type of decision. "That's uncomfortable" is generally not highly valued as a decision making criteria from the business' perspective.

Good Agile coaching will prepare the team for this additional responsibility; it will give them the techniques they need to work through these tough decisions. Good coaching will also prepare managers for the fact that the team will reach different conclusions than the team's traditional managers... and that they may use a more qualitative approach (Eric's "Things just go... well... better... when John's around.") in contrast to management's traditional quantitative one.

The team's perspective on this individual tracking issue should ideally sound something like this:

We understand that it's critical for the business to maintain high productivity. We recognize that individual performance is a key to overall productivity and that our team members will need to be paired with work that matches their skills. When the business' expectations of our team cannot be met with its current capability, individuals may need training or coaching in certain areas, and there may be situations where it's necessary to remove or replace a team member. We will be fully transparent regarding mismatches between current expectations and capabilities so that management can identify opportunities to provide resources, assistance, or intervention. We ask that you trust us not to shirk this responsibility and to collaborate with the team to devise a plan to satisfy this critical business need.

As for the bonuses, year end reviews, etc. ideally, your management would allocate your bonus portion to the team and the team decide how to divvy it up. As Eric says, management's relationship with individual team members becomes less of evaluation and more about career guidance.

  • This is interesting Larry, but the problem we have is that during a particular year an individual would participate in multiple teams, and dollars for raises / bonuses are not aligned with those agile teams. Commented Sep 2, 2011 at 10:14
  • OIC. The recommendation for Agile is to try to keep the teams together and bring the work to them, so you should also work towards that. But your transitional situation is not insurmountable. You can track the team's metrics during the time that individual is on that team (say 4 months on team A and 8 months on team B) and pro-rate the team's metrics to come up with an individual metrics. If metric 1 on Team A was 10 and metric 1 on Team B was 7, then the individual's portion of metric 1 would be (4 * 10 + 8 * 7) / 12. You can calculate the bonus division similarly. Commented Sep 2, 2011 at 11:48

While, I have never worked for an organization that rewarded bonuses to individuals on a SCRUM team for their "individual performance" I can think of a few ways to try giving your upper management this visibility:

Hours Estimated vs Actual: When team members are breaking a story down into development tasks have them place an "hour" estimate on how long they think the story will take. This number number could then be compared to the actual time put into the story.

The last team I worked with was a 100% pair programming SCRUM team. We always put down hour estimates more on our tasks but we never compared this to the "actual" time taken on a story. After writing this I'm actually note sure if this would have an adverse affect on the team.

360 Peer Reviews: Have your team members evaluate each other. There are many different ways a peer review can be performed but the information gathered within the review process is a great tool for not only giving feedback to team members, but a great way to get a feel of a team feels about an individual.

Again I will mention that I have only used 360 performance reviews for team building and feedback exercises...

Ask the team: Like all things subject to change, have you had a brainstorming session with the team? What are are their thoughts on how to give your management this visibility.

  • 5
    If you hold your developers accountable for poor estimates, one of two things will happen: they'll pad the estimates, or they'll avoid doing any work with high uncertainty (new stuff, things they've never done before, etc.). I've seen it have highly adverse effects. I like the other two suggestions though.
    – Lunivore
    Commented Aug 31, 2011 at 16:28
  • 1
    Thanks for the suggestions Jesse; good ideas. We have tried collecting actuals on our waterfall efforts and it has always caused a lot of strife with developers. I'm guessing it would even more so on agile. I plan on asking the team but I was trying to come up with some suggestions before I do. Commented Aug 31, 2011 at 16:57
  • 4
    Don't ever base individual performance review by how precise estimates were. Not only people would avoid taking risks (as Lunivore points) but people would also avoid estimating at all considering it might be risky. Learn from historical data, coach people to improve their estimates but never judge people by their accuracy in estimation. Commented Aug 31, 2011 at 17:29
  • After I had finished typing the actual vs estimated section I had the same reservations but I thought I would toss it out there anyway, as I do agree that this is more than likely not a valid thing to try.
    – Jesse
    Commented Aug 31, 2011 at 19:08

Everyone brought up valid points so far. Two more things.

We can measure hours contributed to a project against % complete for a task to gauge effectiveness for individuals. Some people put in lots of hours for very little gain and vice versa.

We can look at efforts at self- and team-improvement across a time period like courses, mentoring, training within or across teams to add value. In the thick of development we don't always leave time for raising our game. Those agile team members who do and get their work done well are exceptional.

  • 1
    I disagree with you first suggestion of measuring effectiveness by hours contributed against % complete. This encourages team members to avoid taking on work which will speed up the team as a whole over the long run in order to get their own task at hand done quicker. I would much rather see someone take some extra time to make work for everyone else go faster in the future than always be worried about their personal progress.
    – Jesse Webb
    Commented Sep 2, 2011 at 20:35

It has been mentioned already in a few other answers but, unfortunately, it was along side other points which I don't completely agree with. I will add it on its own because I feel it is the only effective way to gain a good understanding of individuals' performance on an Agile team. I will use SCRUM roles in my explanation for simplicity.

360 Peer Reviews
Have all of the members of a team review each other regularly. By all, I am including scrum masters and product owners in this process. The team will spend most of its time working collaboratively within its own bounds so why would you look anywhere else for a good understanding of everyone's effectiveness.

This works especially well when team members are working together on tasks (pairing). Make the reviews anonymous and private (except for the manager who needs to read them) so there are no hard feelings.

I said SCRUM masters and product owners should be included but this may involve including outsiders of the team into the review process because these team members may work with people external to the team. Like POs will interact with customers and SMs will work with other SMs, at least in a distributed Agile environment. Why not ask the customer to evaluate the PO? Why not ask the other SMs to evaluate the one in question? And vice versa of coarse too.

My point is that higher-level management cannot determine this things algorithmically by using metrics or anything of that sort. This is a people process just like Agile itself.


agile coach here. I know we’ve got some answers from managers below that fellow managers love. However, I think we also need an answer from someone with experience implementing full agile, which is what I’ll try to do below. First and foremost, the team is responsible for the work, not individuals. The team must be able to work in an environment without fear. That means, no managers who can fire, or otherwise penalize someone for not working hard enough. Finally, we want to reward teams, not individuals. I mean, the reason we want to have individual accountability is to focus on rewards, and not punishments, right?

The philosophy here is two-fold: trust, and an environment where fast-failure is encouraged.

Trust: We want teams to know they can be completely honest about their progress to sprint/increment goals. We want full transparency, we won’t get that if the team-members don’t trust they can be honest about failures. We trust them to be honest with us, and they trust us to not penalize them for failure.

Fast-Failure: We want teams that are working on a chunk of work that is failing to note the failure, stop the work, figure out the problem, LEARN why they failed, and then proceed. An environment of fear where failure is not tolerated is an environment where failure will continue and not be corrected quickly.

Identifying problem team-members: So, the real focus for the higher-ups here is probably that whole fire-the-lowest-10%-every-year or some such nonsense. If you allow the team to operate in an environment without fear, they will come to you when someone isn’t contributing. I’ve seen this happen quite a bit where one or more members of a team will march to my office and say “X person really doesn’t know what they’re doing, and they are impairing our ability to progress to sprint/iteration goals”. Then you can start the paperwork process to improve performance or replace them.

What do I report to managers? This is simple, report progress to iteration/sprint goals and do it weekly. Focus on business value met, and not individual performance. It is the team that is producing the work, not the individual contributors.

What if the managers insist? Then they’re not an agile executive, and probably need someone with gravitas to help them understand. If they refuse to change their mindset, you will not become agile. Go back to waterfall, and don’t pretend you’re agile.


Calculate velocity on an individual basis. This requires you dive into the task level of the project and also requires discipline (and if need be force put on people by managers) in order to keep people accurately tracking their output on a task by task basis and a project by project basis.

You can come up with running velocity averages for the indivdiuals (and the team). With these averages you can see what teams are performing and which teams are not...then also see which individuals on those teams are performing and which are not.


You will need to custom tailor a solution for your business, but so long as you some how track these velocities, and review past data, your team will get better because each individual will get better...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.