What are the typical role descriptions in agile?

I am supposed to be doing some  blogs on scaling agile, but I was distracted by being very lazy.

But sort of on topic – people often ask me “what are the roles in agile and what are their responsibilities?”

I usually say there are three roles – product owner, team assistant and team member.  People ask me about Scrum Masters and I often say that it is really “Scrub master” for “person who scrubs up for the team”.  But whether I call them iteration manager, team assistant, scrum master or something else, it is a key role.

Then people often ask about testers and BAs … and I say they don’t really need them in agile, unless they do need them.  This seems to annoy people more than help them but I think a lot of agile coaches are giving people the same generic answers.

So here is a slightly different answer.

Agile teams are self organising so the team might invent different roles based on their own context.  Similarly, the team might need front end developers, or llama herders or configuration experts, but agile won’t tell you that … because the roles in your team depend on the kind of work you are doing.

In a typical project, I often find myself looking to fill these roles, even if I have people performing more than one of them:

These are roles I like to have, beyond having just developers.  The team in this example has some of the roles because they are in a large company with a separate operations team, architecture team and so forth. In agile it is ideal if the team that builds the solution also supports it and if the architecture is a democratic “federated” model that evolves through communal dialogue … but that is not the context I often operate in with my clients.

In your case you wont need all these roles and your agile coach should be able to give more guidance when he or she understands your context.  At a minimum they will probably say

Product owner (sponsors, business representative, dude with the money or other titles)

• You need a “product owner” which means someone who makes the final call on behalf of your business or customer.  This person might or might not be the only one with a vested interest but they will be the person the team goes to for a decision if they are not sure.
• If you are evil, the best way to destroy an agile team is to pick a subject matter expert and call them a product owner and then be totally unclear on their decision rights.  They will then either make bad decisions because they are out of their depth, or they will have to double check everything and never be able to support the team.  If you are NOT evil then you will make sure the team and the product owner understand what decisions he or she can make, what decisions the team can make without them and what decisions the product owner needs to go to someone else for.

Tech lead

• The team can be self organising and fully empowered, but they should have to integrate with everyone else.  So a tech lead is the expert in a particular field (Java, Ruby, testing, Delphi, Process Design).  They work with the developers and with the operations team and the architects if those groups are in different teams.  They know when to bring in an outside technical expert, they know the standards to build against and they know the history and strange personality of the technology you are using.

Scrum master/ iteration manager/ Kanban Blackbelt special operative/ gopher/Radar O’Reilly

• The team can be self organising but even so, it is often better if there is one person to SMS if you are going to be late
• The Scrum master is the central communication person in the team, you speak to them when you don’t know who to speak to
• The “master” bit does not mean “lord and master” and nor does it mean “super guru” it means teacher – they are the one who understands the teams work processes (SCRUM, agile, lean, hero based delivery or whatever) so they are the one helping the team develop and evolve a way of working
• People say they remove blockers and obstacles but really the team do that.  The scrum master is the one who facilitates or collaborates with the team to focus their efforts so they can remove their own obstacles.  So if you don’t know who is meant to fix the broken printer then you harass the scrum master, who then finds out who in the team (or outside it) can fix the printer.

After that you only need people to do the work – they are often called team members, developers or contributors.  But what you need in your team depends on your context.

So the pictures I provided are not the “correct roles” they are roles I found myself needing in a core team building a technology based solution.  Feel free to contact me learn more about what they mean, or to add roles as you and your team see fit.  Or, if you have a coach then harass them until they admit that your team might need different roles to the ones they had in their small web development start-up team.  Their job, if you have a coach is to help you move from “it depends” to “it depends on X – and in this situation that means we could consider ZYX”.