Dear Junior
I constantly become surprised of the use of the abstraction ”resource”, and have actually not really understood how it has become so popular. Abstractions are used to discard irrelevant details to be able to focus on what is important, e g when we write a class Customer and actively omit the shoe size or waist length (unless we are in the shoemaker or tailing domain). However, the way “resource” is used by a lot of project managers does not fit that description.
Everyone that knows anything about system development does also know that one java programmer is not the same as another java programmer. The difference in skills might make Alice, who happen to know a lot about databases, totally impossible to replace with Bob, who is an expert on unit testing, but know little about databases. Not to talk about that Cedric and Dawn just become a killer team when working together.
OK, I understand that if you are the VP of Ericsson’s mobile device division, it might be interesting to talk about groups of a few hundred developers (resources), because at that level statistics will level out stochastical differences between the exact composition of each team.
That said, most development groups are not a few hundred people. They are five, ten, twenty, or fifty individuals.
If we are to make dinner at home I do not look around and say “we have three resources”, “someone need to chop vegetables”, and “allocate 'vegetable chopping' to resource number two”, because that might end up with a sharp knife in the hands of my two-year-old son. Even if we are all my siblings, parents and in-laws (which might add up to twenty people), not even then does in make sense to “deidentify” them to resources – because some of them are good at making sauce and some are crap at that trade.
So, when planning the department’s job for the coming quarter or year, why not say: Lisa, Per, Ashok, and Yasmine will work on CogStat; John, Hassan, and Helga on FormFeed, but Helga will also help out with persistence in CogStat; finally Jari and Dimitri will prototype CaseSmart and also help out with CM problems. Probably the people involved will come with suggestions, improvements and problems; plus that they feel comfortable in having a personal plan. Saying: Cogstat 4.5 resource, FormFeed 3.75 resource, and CaseSmart 0.75 fulltime resource will only cause confusion and not help creating an efficient work place.
When it comes to the bottom line it is really simple: Using the information that people are different (in relevant ways) must logically lead to a more optimal solution (stable release plans, productive teams, happy members), than discarding that information.
I constantly become surprised of the use of the abstraction ”resource”, and have actually not really understood how it has become so popular. Abstractions are used to discard irrelevant details to be able to focus on what is important, e g when we write a class Customer and actively omit the shoe size or waist length (unless we are in the shoemaker or tailing domain). However, the way “resource” is used by a lot of project managers does not fit that description.
Everyone that knows anything about system development does also know that one java programmer is not the same as another java programmer. The difference in skills might make Alice, who happen to know a lot about databases, totally impossible to replace with Bob, who is an expert on unit testing, but know little about databases. Not to talk about that Cedric and Dawn just become a killer team when working together.
OK, I understand that if you are the VP of Ericsson’s mobile device division, it might be interesting to talk about groups of a few hundred developers (resources), because at that level statistics will level out stochastical differences between the exact composition of each team.
That said, most development groups are not a few hundred people. They are five, ten, twenty, or fifty individuals.
If we are to make dinner at home I do not look around and say “we have three resources”, “someone need to chop vegetables”, and “allocate 'vegetable chopping' to resource number two”, because that might end up with a sharp knife in the hands of my two-year-old son. Even if we are all my siblings, parents and in-laws (which might add up to twenty people), not even then does in make sense to “deidentify” them to resources – because some of them are good at making sauce and some are crap at that trade.
So, when planning the department’s job for the coming quarter or year, why not say: Lisa, Per, Ashok, and Yasmine will work on CogStat; John, Hassan, and Helga on FormFeed, but Helga will also help out with persistence in CogStat; finally Jari and Dimitri will prototype CaseSmart and also help out with CM problems. Probably the people involved will come with suggestions, improvements and problems; plus that they feel comfortable in having a personal plan. Saying: Cogstat 4.5 resource, FormFeed 3.75 resource, and CaseSmart 0.75 fulltime resource will only cause confusion and not help creating an efficient work place.
When it comes to the bottom line it is really simple: Using the information that people are different (in relevant ways) must logically lead to a more optimal solution (stable release plans, productive teams, happy members), than discarding that information.
In the end we all know that individuals and interactions make more of a difference than processes and tools.
Yours
Dan
ps This is an issue where I think agile is different
Yours
Dan
ps This is an issue where I think agile is different