[Kindle Book] The God with a Red Dot - "Akki, a teenage boy growing up in an average middle class family in Suburban India, struggles to pick a God to pray to. He sees pain, in his family and ...
As per an advisory issued by The Union Ministry of Health and Family Welfare India, we will no longer be processing or shipping any order till further updates.
Ideally, an XP team consists of all talented and experienced people. Every person is assumed to have good communication skills, technical skills, ability to analyze and synthesize, understanding of business drivers, ability to make trade-offs based on business constraints and the ability to work as part of a team. Indeed, there probably are thousands of people who qualify on all these counts scattered around the world. But IT is a pervasive beast. It touches almost every aspect of modern business. IT is also labor intensive. The demand for really good people outstrips supply by a factor of hundred if not more. IT vendors who practice XP are therefore forced to move away from the ideal of more or less homogeneous poly-skilled teams.
Instead, we hire people who have a subset of the above skills and assign them to specific roles in a team. So we have roles like developer, analyst, QA, manager, UX dude/dudette etc. It is essential to recognize that this arrangement is a departure from the ideal - a compromise driven by market reality. How we look at roles depends on our model of the ideal world. If you agree with the XP ideal, then roles are labels attached to the activities on a project. e.g. performance tuning activity needs developer role, activity of scope negotiation needs manager role.
But all too often, we lose sight of the ideal and think of roles as labels attached to the people on a project. e.g. person A is a manager, anything she says outside her labeled area of competency should be taken with a pinch of salt, person B is a developer, anything she says outside her labeled area of competency should be taken with a pinch of salt, and so on. We forget that the labeled area of competency is merely a mutual agreement at the time of recruitment. We end up discounting the credibility of people outside their labeled domains.
This kind of thinking also magnifies capacity constraints in a team. Say we have 4 people with label QA and 12 people with label developer on a team. What happens when stories start piling up in QA? We are less likely to see if some developers can add temporary capacity to QA. Oh no, that would never do. Developers can't test. They are not wired to test. Mass stereotyping sets in.
Soon people start buying into their labels. Developers refuse to test. If you can communicate well, you are suspect as a developer. Managers shy away from writing code, or (shudder) gaining even basic user level technical competence. They go about saying "I can't handle technology", as if it were a feather in their cap. We become more and more entrenched in the silos created by our labels. Truly ploy-skilled people get disheartened in the process. A person with a label of analyst may have a great aptitude for domain modeling. But her inputs may be sidelined by developers. After a while she either starts believing in her artificial limitations or she starts looking for another job where her skills are more broadly appreciated.
It is no good to call everyone consultant and then use a different labeling scheme when it comes to staffing projects. To the extent of their skills, people should get to play multiple roles within a single project. Oh, that complicates staffing. So? Should the tail wag the dog?
Organized religion came about partly as a result of our need for identity and self-worth. It is probably reassuring to say "I belong to this group" and then move on to thinking "My group is better than the other group". We may have outgrown traditional organized religion but we seem to be falling for newer versions.
Your post is based on the false premise that roles can be interchanged arbitrarily. Let me explain myself:
Hardly: developers are able to fulfill testing roles but hardly ever the other way around. Managers programming? Nevermind that, unless they've grown from a core developer's position and then only recently and in de the same space (Java, .NET, etc.). Am I stereotyping now or am I speaking from experience, you know... from reality.
It is often claimed by Scrum evangelists that there should be no single point of failure and people should be able to fulfill most roles in their teams to provide high availability and increased predictability. Your post seems to underline exactly that notion. Your entire point seems to be increased availability for solving piled up stories. Congratulations, you've managed to reduced the level of various competencies and roles to the level of the lowest common denominator, a gray area that exceeds in no single quality. No, I'm not saying specializing is necessarily best, but it has been proven that the human mind produces the best and highest of quality products when it is doing what it likes, and it likes what it does best, especially when it is being recognized. It comes from and generates motivation, one of the primary pillars of a healthy team.
I dread the day my managers check in code and my testers assess story points. Especially when the reason is because stories are piling up as you say, in which case you've failed to apply Agile in the first place: One of the proclaimed notions of the Agile methodology is that stories *don't* pile up. That's the entire point: predictability, transparency, time management through abstraction, sprints, velocity to avoid piling up stories. Piling up in QA? This should never happen in an Agile setting to begin with. What, you're getting your stories tested in batches? That's not Agile at all. And even so, it is widely acknowledged that code is the most complex when it is arriving in its final stages; the codebase has arrived in a state where many bugs/workarounds/fixes have been applied already and the code inherently increases in complexion quadratically as everything needs to integrate with the rest. It is exactly in this stadium where non-professional or inexperienced 'developers' do the most harm. Hell, it's hard enough to get developers to develop a good product before this phase, let alone non-developers during!
Yes skills by extension, not by people but by activities. That was your point right, hiring people not based on a subset of skills but rather by what activities they could perform spanning multiple roles? Your gripe seems to be the hiring process geared towards singular roles, so you advocate a different mindset that allows for multi-disciplinary teams. This way other people can jump in secondary roles to handle piled up stories -conveniently the only example you mentioned as almost any other problem can't be solved this way, and you don't even need a different hiring procedure: any developer can take on a testing role-.
This is a Contradictio in terminis: You want a team that can handle arbitrary downspikes of any role (developer as QA tester), yet you counter my statement of the false premise of arbitrarily interchanging roles by falling back on the extend of specific skillsets of people. If taken to your absolute ideal, or maybe an exaggerated version, everyone can fulfill any role if the hiring process/mindset was fixed for this. And that's where my rant came in, as you end up with a mediocre at best team, since you would need jacks of all trade masters of none.
It's too bad you kept it so vague, because you'd realize the extend is rather short and unrealistic to be mentioned in a broader context.
I don't mean hiring/recruitment when I say 'staffing'. When I mean recruiment, I say 'recruitment'. 'Staffing' is also referred to as 'RM' (resource management) in consultancies. It is the act of building a team out of a bigger pool of talent. So my post is not a presciption to change the way we hire. I just want to encourage RM to recognize that people are multi-displicinary by nature. In the name of operational efficiency, our industrial society tries to coerce people into being uni-disciplinary cogs in its giant wheels. It ends up devaluing human potential in the process.
I don't care if you mean hiring or staffing, you're beating around the bush with wordplay. The point stands for staffing, which is to say you keep ending up with a mediocre team whose members can fulfill multiple roles.
Exemplary blogging: you've made no practical point with your post and failed to address any criticism by using either silly wordplay or the condescending strawmen card. Real mature.
Well, It seems like in such situation 'language' can be serious tool to define, or un-define, 'boundaries' of presumed roles. As you said, labeling everyone consultant might not be the right thing but there definitely is need for something more generic here. Do you think six-sigma sort of labeling in terms of experience in play-ground helps? Something like everyone is 12'th player but experience level (in being a 12'th player) matters when it comes to labeling (12'th player for 20 years might not be great example for cricket field though :))
I feel this is a natural 'evolution' as we move from specialist based approach to generic based approach. While I do no see it replacing the specialization based labeling but hiving off another 'acceptable' branch of skill recognition (and grading). Maybe we will soon see agile, super agile, cannot-rest-by-bum roles soon which will indicate resource's ability to be agile (even in accepting levels within role).
I don't know six sigma but I think labeling people should simply be avoided. Then how do we assign people to projects? Use a full text search on their professional profiles. Assuming they have described the work they have done, they will show up in relevant searches. I am assuming here that we don't want 'efficient', 'robotic' lookup and assignment of 'resources' to projects. The person in charge of staffing better know the people in question. Yes, this approach will not 'scale' but who says it must be necessarily scalable? This is just plain dogma of the knowledge industry.