Clarifying agile roles – speed dating?

I went through this quick meeting with an agile class recently and I said I would post this for the crew to refer back to.

In agile teams there are a couple of core roles and then the rest depends on the kind of work the team does.  But we can give some more clarity than this, as I have previously discussed here.

Even so, the role of the Scrum Master or Product Owner or Tech Lead or even others will vary from project to project and even sprint to sprint.

So I often have people sit down together and actually tell each other what they think they are in the team for.  Essentially I get them to go through these questions that I got from a book called “Stand Back and Deliver.”

But I have actually taken to speed dating now.

For example I get my core “leadership” crew to each state what they deliver to the business and to the team … and then see if they agree or disagree with each other’s claim.

Then in a retrospective or a team meeting in “sprint 0” I get the team to state what they think the (scrum master; or other role) is delivering to the team.  I then compare this to what the person doing the role thought they were doing.  It leads to fun discussions and the revelation of surprising differences in opinion.

In bigger teams I even do this as a speed dating exercise.  Each person develops their rough role profile and then sits with another team member.  They have three minutes for one of the team to describe their role and have the other question them or comment on things.  Then the roles are reversed and the other person presents their role in 3 minutes.  Then people move to another person and the process repeats.  after everyone has spoken to 3 people I get them to sit back and redo their “lazy role profile.”  Sometimes we even have some questions to discuss as a group.

Sometimes people have multiple roles (or even roles in multiple teams) and they often have a million things they need to be doing. So I then get them to explain what their most important “top 3” tasks/accountability/deliverables are. I follow this with we would know if they were succeeding and what help they need from others (from the team or from management or even what skills or tools they will need).

Finally, I often find that the product owner is set up to fail because they are supposed to make all the final business decisions for the team … but others actually make all the decisions.  So I get the Product Owner and maybe others to give examples of decisions they make or defer to others etc. In other words their decision rights.  I then compare this to what others think and again find potential misunderstandings or opinions to deal with.  Here is a fictional example of the “decision rights” for the Scrum Master to show what I mean.

I don’t want to give away my sophisticated coaching techniques, but I do a similar exercise when I am coaching someone.  I ask them to fill in the same info and then check what their boss/subordinate/peer thinks.  It still amazes me how often this simple exercise highlights potential conflicts or issues that can be resolved before things are going cactus.

Even if someone has a million things they could be doing it is really helpful to highlight what has to give if they are going to deliver the most important components of their job.

This is all just an adaptation of a role profile I use for BA’s on projects but for some reason it works much better in agile teams if I have people pitch their roles to each other in a workshop.