I was recently re-reading Martin Fowler’s article The New Methodology when I came across a passage that stuck with me:
One of the aims of traditional methodologies is to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren’t so important, only the roles are important. That way if you plan a project it doesn’t matter which analyst and which testers you get, just that you know how many you have so you know how the number of resources affects your plan.
But this raises a key question: are the people involved in software development replaceable parts? One of the key features of agile methods is that they reject this assumption.
One of my biggest pet peeves is when managers and planners refer to people as “resources.” I get this visual of a bunch of managers sitting around a table and trading little chits that represent people until everyone is happy with what they have, but all the chits are the same… just commodities to be pushed around from project to project.
When you treat people as interchangeable cogs in a machine, you miss several important factors about your team members:
- People are not equivalent pieces. I refer you of course to the ever-popular book The Mythical Man-Month by Frederick Brooks. If I have estimated1 that two people can do the work in six months, increasing that to four people does not mean that we will get it done in three months. Team members all have differing levels of expertise and productivity, differing skills and motivations; you must know how to leverage these individual talents rather than lumping them together as a whole.
- People bring the greatest benefits and the biggest hindrances to the project. When you reduce them to a column on a spreadsheet, you are naïvely discounting their individual personalities and quirks. People can have breakthroughs that cut development time in half. They can also have a family emergency and lose you a week of production.2
- People are perceptive. They know when they’re being treated as faceless automatons rather than real human beings, and they will resent you for it. Don’t ever believe that your team members aren’t keenly aware of how you talk about them behind closed doors.
- People have preferences and motivations. Assigning people to tasks that they may be good at but hate is counter-intuitive. Yes, Bob may be a database whiz, but if he hates the reporting engine, assigning him to fixing the reports isn’t going to be the best utilization. Assign people to tasks that they enjoy, even if it’s not their strong suit; they’ll be more productive and learn a broader range of skills. Conversely, don’t let people pigeon hole themselves—ask them to branch out every once in a while and leave their comfort zones.
- People have lives beyond work. Don’t plan for people to have 100% attendance. Don’t even plan for them to work 40 hours per week. As I mentioned above, people are perceptive, and if they feel you are treating their personal lives as secondary to work, they will resent you for it, and morale and productivity will plummet.
1I’ll skip past the obvious argument for the moment that I shouldn’t be estimating for the team anyways.
2This of course also points out another problem—trying to estimate too much ahead of time. People can and will ruin your project plan the moment you publish it, for better or worse.
posted on September 30th, 2009 at 8:25 am
← Back to articles