In reponse to yesterday’s post, Ken Flowers commented:
…I’ve wondered if there are times when the retrospective should call out blame. That is, on some projects the real problem is that someone didn’t do their job. I believe that this kind of feedback should be one-on-one, but that doesn’t change the point that it is a personal problem not a process problem: “Joe messed up.”
Maybe.
Maybe it is a process problem.
If this is an agile team–or any self-organizing team–where team members make performance commitments to each other not to a manager, Joe’s not doing his job is a team problem, and it might be problem with their process.
I’d look at questions like these:
Why wasn’t obvious (if it wasn’t) that Joe was not finishing his work? Are the chunks of work too big, so that we don’t know until it’s too late that some one is stuck? Are we updating our “work remaining” estimates so that we can spot tasks that are taking longer? How can the team make status more visible so that problems don’t hide?
What kept Joe from asking for help (if he didn’t)? Is it part of our team culture to reward individual persistence and punish asking for help? What can we do to make it acceptable–even business as usual–that people ask for help quickly when they are stuck?
If everyone was aware that Joe wasn’t doing his work, What is it about the way the team interacts that kept Joe’s non-performance from being addressed during the iteration? Is the team avoiding giving feedback or shying away from conflict? How can the team improve their ability to address issues like this?
If Joe’s done his job it the past, What obstacles (at work our outside of work) might have prevented Joe from doing his work this time? Can the team or coach remove the work-related obstacles? If the obstacle is outside work, can Joe get some support to remove it (maybe through an Employee Assistance Program)? If it’s a temporary problem (e.g., a problem with day care or an illness) can the team accomodate lower productivity for a short time?
Is this work Joe likes to do? If it’s scut work, is Joe always stuck with it? Is there a better way to distribute the scut work?
Does Joe have the skills to do the work? What does that mean for the team? Can the skills he does have be used more effectively? Can he reasonably develop the skills?
On the other hand, if this is a traditionally managed project where people report status to a manager, I’d wonder about how the manager was doing his or her job relative to the questions above. But then it’s a management problem, not a team problem, and I wouldn’t put the focus on Joe in the retrospective.
And I agree, on a team where people report status to a manager, feedback to Joe needs to be private. It might come from the manager, or it might come from a peer. (And I’d want to give feedback to the manager on the impacts to the team of not managing.)
AND even in a case where Joe plain old didn’t do his job, it would be more helpful to give Joe information about his behavior/work results and the impact on the team.
Then Joe has choices:
He can choose to start doing his work, if he’s been choosing (up until now) not to do his work.
He can make the courageous choice of saying he doesn’t have all the skills he needs and ask to pair with someone to improve his skills or seek training.
Or Joe can move to another part of the company where he does have the skills to be successful.
And if Joe chooses not to do any of those (or can’t gain the skills in the timeframe needed to meet organizational goals), the team coach or the manager can take the courageous choice to move him off the team. It’s hard enough to build software with out carrying someone who can’t or won’t do the work. Some times no body is better than a person who is just a warm body.
(I know of self-organizing teams who move non-performers off the team without the coach or manager getting involved.)
