Individual accountability on agile projects

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

http://www.jacobsingh.name/content/velocity-tracking-agile

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...