11.01.09
Abolish Roles
A few weeks ago, I noticed a theme developing in my Twitter feed. I had some friends tweeting from the Simple Design and Testing conference in Pittsburgh, and another friend tweeting about this blog entry. At the same time, I was working on some XP course material and was reminded of Kent Beck’s words “…[taking] commonsense principals and practices to extreme levels.”
So in the spirit of eXtreme Programming, I propose what I believe to be an interesting thought experiment: if self-organizing teams are good, then we will always treat the team as a unit; never drawing attention to specific roles.
This is interesting because success or failure should be measured as a team. If a developer on the team does a great job, but no working software is delivered, the team failed: therefore, the developer failed. If a tester on the team does a great job of providing test coverage over one, small part of the overall work for an iteration but no Stories are completed, the team fails: therefore, the tester failed. If the Iteration Manager does a great job of removing roadblocks and insuring work is driven from a prioritized backlog, but the requirements are unclear and the Demo fails, the team fails: therefore, the Iteration Manager fails. In short, any individual team member’s success is completely dependent upon the success of the team.
This should lead to a team where the concept of roles is, at a minimum, blurred. The team does whatever is necessary to attain the stated goals: meaning, individuals on the team do whatever is necessary for the team to succeed. There is only one role: team member.
So why is this a thought experiment? When it comes to getting real work done, we need competency in certain skills. It would be difficult — even silly — for a company to list job postings seeking “Team Members” without any specific skill set. We still need experts. We still need people with the specific ability to turn ideas into code; to effectively facilitate a team; to expertly test a system. Those roles, and more, are crucial to making real progress on software development projects.
Being an individual is easy. Working effectively on a team is a worthy challenge. What are some ways you are encouraging your coworkers to become teammates: to put the interests of the team ahead of their own interests/concerns/agendas?
allan kelly said,
November 2, 2009 at 6:00 am
True, I think teams – especially those that claim to be “Agile” need to blur the roles but I also think a lot of discussion on this topic has been over simplistic.
The way Agile is often advocated it is developer centric. We talk about team members doing code, testing, perhaps a bit of business analysis or some project management. If you are a coder this might be possible. If however you are a Tester or a BA asking you to jump in and write Java is a little extreme. You might well do more damage than good.
There is also a scaling side to this debate. When a team is small (say 2 people) then it makes more sense to blur roles and overlap them. In such a case at least one of these two people needs to be coding, and probably both. Without the code you have nothing.
Then as the team grows it makes sense to re-introduce roles. This can help prevent people getting in the way of one another. Rather than have 6 people coding, testing, BA’ing, managing and what not it seems to make more sense to have someone specialising in the “what” (analysis and requirements), someone else specialising in QA and the other four coding and helping out as needed.
Pablosan said,
November 7, 2009 at 2:10 pm
I completely agree. To be clear, I am not advocating eliminating roles, and my attempt at being clever has probably confused the matter a little. My point is more about elevating the status of the team. Individual contributions are still valuable, and specialists are still needed, but the more the team is emphasized, the healthier the project will be.
And I know we have both seen the concept of “my role” abused, to the detriment of the team (e.g. “I just write code: it’s QA’s job to test it”). The danger in identifying roles is that it can be misused to support the “it’s not my job” excuse. So, while expertly filling a given role on a team is important, “the needs of the many outweigh the needs of the few… or the one” (thank you Mr. Spock! ). Individuals contribute: the team succeeds.