There’s some current talk in the Agile community about making developers more accountable in the agile process.  Apparently, the problem is that developers will commit to delivering too many features in an iteration, and if they slip on the features, they say “so what… we’ll do that in the next iteration.”  That is laziness, plain and simple.

I’m actually going to side-step that issue completely.  That issue happens, and folks are talking about it.  Good.  However, I want to add another issue to the table: project managers who are incompetent, and then blame the dev team for failure.

I’m ranting here folks.  This is a reaction to the notion that we should hold developers accountable (which I agree with) in a community that doesn’t recognize the role of a PM.  However, agile evangelists aside, the rest of us have to live with project managers, and they can be a tremendous asset or a massive liability. 

Here are some of the counter-productive behaviors I’ve observed. 

Focusing on tasks, not functionality – where do I start?  I could rant for days on this self-defeating pattern, yet I have seen nearly every project manager fall into this mentality during project work, some for a day or so but others stay there for the duration of the project.  Even if you shake the really egregious ones by the collar and scream, it may not help (except that you may feel better for 20 seconds or so), because this is a mentality.  Some PMs think that focusing on tasks is the RIGHT thing to do, and it is not.  The customer doesn’t want a task to be completed.  They want functionality to be delivered. 

The net effect of this focus on tasks: marking a task complete (and rewarding folks for it) when a developer says “it is done” without demonstrating functionality, quality, unit tests, and compliance to standards and interfaces.  The PM is the enforcer who must understand that the customer buys these things, and if they don’t insure that these things are in the product, they will not be.

Focusing on process instead of people – This is a novice mistake, but I’ve seen it a lot in high-ceremony environments like PSP/TSP and XP.  The process is important.  It is how everyone comes together on the problem space.  But the people are important too.  Leave room to bend the rules if the people will benefit.  Make a connection to the individuals.  Listen to their needs.  Understand their schedules.  If a person needs to leave a 4:30 to pick their kids up from daycare, don’t schedule the team meeting at 4pm! 

Counting yourself outside or above the delivery team – People are not perfect.  When the list of tasks is estimated at the beginning of a project, it will not be correct.  There will be tasks missed from the plan.  There will be questions that need to be answered “out of order.”  There will be times when you really need to get the customer in the room, even if it makes you look bad, because the developers don’t have what they need.  Swallow your pride.  You are the servant of the project.  The developers are not your master, but if the developers need something, and the alternative is a sacrifice of quality or time or design, then jump.  That’s your cue to really shine.  Be a part of the team.  It’s your delivery too.

Celebrating completion instead of correctness – You are responsible for a large part of the culture of a project team.  You can set the tone for how people communicate, how they share, and how they feel when a release goal is hit.  Change your outlook away from “milestones of activity” and towards “user acceptance” by throwing a celebration for the team when the user is satisfied with something.  In one shop I was in, we would put a stuffed monkey in the cube of the person who had achieved acceptance.  It would move frequently.  In another, we decorated the doors, or handed out colorful banners.  Building joy around correctness and acceptance will build a culture of quality and team cameraderie. 

Failing to understand the mathematics of human achievement – I saw a project team that was filled with young developers commit to achieving 8 productive hours in a day on a highly-visible, time criticial, three month project.  When I heard this, I yelled.  I went to dev management (I wasn’t on the team) and complained.  I went to the PM.  I even went to the customer and said that this committment was absurd.  All simply said “the developers believe it is possible and we will hold them accountable if they don’t meet it.”  WRONG.  If you agree to doing the impossible, (jump onto a train moving at 90 miles per hour), I would be a FOOL for saying “I’ll hold you responsible if you don’t.”  The impossible is still the impossible.  A 200% improvement in productivity over the average, for a 3 month period, is impossible.  You have to know enough to know when someone is making an absurd committment, and you have to stop them.  It is your project too.  Blame cannot be allowed to roll downhill when this kind of mistake is made. 

So, folks, if we want to hold a conversation about holding developers accountable, let’s also hold a conversation about holding project managers accountable.  Let’s find a way to measure the PM as well, and let’s hold them accountable for failing these points.  It is their responsibility too.