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.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

2 thoughts on “Developer accountability? How about PM accountability!”
  1. This article has come out from heart. I remember an instance where we were struggling to build a functionality that was extremely complex and the whole team has just drained out of ideas on how to do it.

    Then suddenly one day, when I came up with a suggestion, the PM jumped at it and said, I’ll give you 100 mandays to do it. All I had given was a suggestion. No study has been done on the suggestion. Nothing. From where did he come up with 100 days estimate, is still a mystery to the entire team. But this guy just walked over us with his ever-inflating ego and committed 100 days. And as you’ve rightly said in your article… "He held me accountable". But no one questioned him.

    "I have just been shot and held responsible for coming in the path of the bullet. And the man with the gun reins free."

  2. You mentioned the mistake that some people make of focussing on process instead of people.

    I like agile methods such as XP, but they tend to assume that everyone is the same, and likes working in the same way. In reality, some people are keen to be promoted into "senior management", others want to spend as much time as possible with their families, and some

    want to become technical experts in certain areas.

    Whatever method is used needs to be adaptable, so that everyone’s individual goals are aligned to the goals of the project as a whole.

    If people perceive that they are going to achieve their goals, they will be contribute more to the project, and this would be far

    more valuable than adopting the latest process.

Leave a Reply

Your email address will not be published. Required fields are marked *

eleven − 7 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.