There are, to my way of thinking, some very good functional reasons for the rigidity of those role descriptions and definitions. The main one is that everyone knows their basic functions. They are simple:
In the service, everyone was a Grunt first. You had to know how to kill(shoot, toss things that go boom, set up stationary things that go boom when the other team was properly aligned as a target, avoid the other teams things that go boom, keep oneself reasonably serviceable in nasty environments, etc...) Everyone had the same basic skills and there were metrics, and if you didn't measure up, you were out(which is a big favor to everyone including the ousted; better ousted than dead).
An individual on a development team should have the basic skills to program 'something'. Otherwise, they should not be on a development team. The basic metric is you can write some sort of functional code or you can't. If you can't, what the hell are you doing in software development?
In the family, the eldest helps build the basic skill sets of the younger and protects them from ignorance. Up until their own ignorance/stupidity(in my case) gets in the way of that, which is when mom/dad step in and make sure the problem isn't being handed down the line. Some pretty simple metrics their too, though I am sure it varies from family to family.
In the service it is rank and rank type(Officer/Enlisted). The skill sets may differ(supply vs motor transport), but even so, those support roles are still aimed at the basic skill sets which enable the core mission.
In a development team, there may be a SCRUM master or a technical lead or a developer. Each has a role which is aimed at the basic mission which is writing serviceable software.
In the family, well... I won't go there, as the roles in many families vary in many ways and often interchange, which is really cool. Never-the-less, the functioning families I have encountered have designated roles, and each knows what their current role is. Each role maintains the members of the family as well as the family unit itself.
The bothersome thing with all these methodologies is that they keep changing things up. What they all really boil down to (at least in my neolithic mind) are a constant re-shuffling of the basics above. That continual shuffling around undermines the basis of how I function. I need to have a clear understanding of what my role is and what the role of those around me is. I expect to be expected to understand and contribute at some level in the basic skill sets regardless of my role. I think part of the reason that this article hits the nail squarely on the head ( Joel Spolsky ) is that it becomes easy to 'game' a system when the system is in constant flux. When it comes to metrics in a changing system, about the only measurable thing is the change itself. Thus, the metrics become frustrating because the standard keeps changing, or at least the way it is talked about and understood.
Every role needs to be based on the functional skill sets which get the job done. It may be organizational, or technical - manager or architect for example. That role is still based on applying the skill sets to the task at hand. I question whether one can do that without having a functional understanding of those functional skill sets. And that is another part of the reasons those hucksters sell what they do, the way they do... everyone wants the newest paddle for the canoe and they are so busy looking at paddles, they don't see the canoe drifting away...
Ok. Enough... I will stop. (Past?)Time to get off my high horse... :-)
...the majority is always wrong, and always the last to know about it...
Insanity: Doing the same thing over and over again and expecting different results...
A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct
In reply to Re^3: Selling swimsuits to a drowning man
by wjw
in thread Selling swimsuits to a drowning man
by locked_user sundialsvc4
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |