Agile Role playing

Agile Team Roles

Rob Bowley has picked up the Agile Roles and Responsibilities Portia and I described on the Agile Coach site.

I had several goals when we published these:

• Explain what’s expected of people as they join an Agile team
• Create a smoother transition from traditional roles into Agile roles
• To emphasize the importance of every Agile Team member implementing the Agile values
• To make it clear that the whole team works together to take up all the responsabilities we’ve listed

The role and responsibility descriptions are a starting point for your team to agree on responsibilities. Each team should customize the responsibilities to fit their changing circumstances. I’m sure we can improve the descriptions and explain the responsibilities better.

I am not my role! I’m a free man!

S: So, you’re a java developer.
P: I’m not a java developer.
S: I’m sorry, I thought you said you developed in java.
P: I currently develop in java. That doesn’t mean I AM a java developer. I keep my options open.

I now regret using the word ‘Role’. It is almost universally misused:

• People will identify with the roleand thereby limit themselves: “I am an X, so I can only do Y”
• People will identify with the role and thereby limit others: “I am an X, so I’m the only one who can do Y”
• Roles can lead to Silo Thinking: “It’s not my responsibility, it’s not my problem because it’s not my role”. This gets  especially bad if the roles are equivalent to positions or even departments. Imagine the dysfunctions you could create if you had an Analyst department, a Development department and a Test department each trying to optimise their own little goals.
• Roles get tied to compensation and evaluation, so that every responsibility you take outside of your role is at best a waste of time and could well be detrimental to your career.

Because many people have had negative experiences with roles, they react negatively to those Agile roles. To me, roles are no more than convenient sets of responsibilities. The important thing is that we as team members take those responsibilities.

I’m just playing

I see roles as an actor sees them. Today, I play an Agile Coach. Tomorrow, I’ll play an Agile Project Manager. Yesterday I played Agile Business Analyst because we urgently needed to work out some User Stories.

Another metaphor is that roles are like programming interfaces. An interface means I can expect certain things of anyone implementing the interface. One object can implement many interfaces. An interface can be implemented through the collaboration of multiple objects.

A common misconception is that everyone on an Agile team must be able to play every role. We all play roles according to the need of the team AND our abilities (and interests). But the more people who can take on a role, the less chance there is of that role becoming a bottleneck. Multi-skilled teams can react quickly to changes in needs.

Which roles do you play? Which responsibilities do you take on? Do you get typecast?