We all know that “Individuals and interactions” are important. I believe that getting explicit agreement on how the team will work together is fundamental to a happy and performing team.
One exercise I have run in various orgs, from fashion retailers to hospitals, is a simple mapping of roles but is highly effective.
How it works
Before the meeting takes place:
- The team members identify what duties (incl. skills, abilities, tasks, etc) the team needs to perform. For example, designing the product/service, checking the code, agreeing the backlog, liaising with clients, controlling the budget, signing off the product/service, testing the output, writing the code
- The facilitator writes each duty on a separate index card
- The facilitator creates a map of the various roles and/or areas that the team is comprised of. Sometimes I make them specific roles (such as PO, Scrum Master, Development team) and/or areas of the business (Scrum team, marketing, finance, board, operations). I don’t use people’s names though. The format is flexible: it could be column headers on a wall, circles on a large piece of paper, buckets with labels, etc.
During the meeting:
- The goal of the meeting is for the team to agree who is primarily responsible for each duty. It’s not really about ultimate, wring-able neck responsibility; it’s about who should make sure it gets done (you could say, “who is the person who should feel guilty if this duty doesn’t happen?”). Feel free to have a discussion about what the team means, but don’t get sucked into a lengthy debate
- The facilitator hands the stack of index cards (with the duties written on them) a member of the team
- The team member takes the top card, reads it aloud, then places it on the role/area that they believe is primarily responsible for the duty (clearly stating where they are placing it)
- They may offer a brief (i.e. under 1 minute) explanation for their choice if they wish, but do not have to
- The team may then comment on whether they agree with the card’s placement:
- if they all agree, the team member hands the remaining stack of cards to the person on their left, and the process is repeated until all cards from the stack have been successfully placed on a role/area.
- if anyone disagrees, they may ask for clarification or suggest an alternative location for the duty. If the team member who placed the card is persuaded to move the card and consensus is reached, then the cards are handed to the next team member. If consensus cannot be agreed (or if the debate seems to be going on for too long), the facilitator takes the card and sets it aside (possible making notes of any salient disagreement points). This becomes the ‘contentious’ pile
- Once all the cards have been placed on a role/area, or on the contentious pile, the facilitator should allow participants a chance to question any of the cards placed so far
- Note: if the meeting has run for a long time to get to this point, now is a good time to take a break
- Once the group reconvenes, the facilitator brings out the ‘contentious’ pile and the group discusses them in detail. This is the crux of the whole meeting as these are the duties that will cause friction within the team if not dealt with, so don’t rush it
- Finally, after all the duties have been assigned, make sure the team all agrees they are happy and document it.
- However, this is only the beginning: this is a living document so it will change as the team matures.
It is sometimes a good idea to have less defined, amorphous groups that tickets can be assigned to. This is usually applicable when duties relate to people outside the team (such as “operations”, “finance”, “clients”), but can also work with large groups within the team (such as “the development team”). This group may choose to have a follow-up meeting to discuss their duties and assign them to specific roles or people.
You may find that the team needs to speak to people outside the team for some of the duties: as a facilitator, make sure that you get a commitment from somebody to take the responsibility for such an action and, ideally, get a timescale for them doing so. Until they complete that action, the workshop doesn’t have a satisfactory conclusion. Make sure the team agrees with any output from the discussions too.