“You are not the only person who has violated the stated rules today, just the most recent. I want to ask the team a question: Are these agreements truly reflective of your intended behaviors? Because you are not only breaking you own rules, you are also failing to take action or hold each other accountable to them. If I weren’t here how would you normally proceed?”
Vince said, “Ultimately you must be able to hold each other to account for your working agreements and feel responsible to each other for your behaviors. Let’s talk about what would need to happen to make you comfortable doing that”
This chapter in the book then proceeded with Vince then finding out the reasons why the team can’t hold each other to account over these rules, and did another walk through to create a new set of rules the team through they could up hold.
Why build a Team Charter?
Meetings need rules, like “punctuality”, “respect other people’s view point” etc… otherwise you just have a minor level of anarchy — where some people think it’s ok to turn up to meetings (or events) late.
If the Scrum Master tries to impose even the most logical of rules on meetings, he/she won’t get a lot of buy-in, as it’s one person trying to solve a problem in their own way. You want to get the Dev Team to solve problems in their own way (own the problem), so they come up with their own solutions and thus own them.
Scrum Teams also need to have an agreed set of values and expected behaviors, otherwise — especially in forming/storming teams — you may have one person who goes in a different direction to what the team were expecting, a no one feels like they can pull that person up.
Team charters are all about finding out what everyone in the Dev Team actually cares about — the common denominators — and then using those to build a value and rule structure.
Why do we need to this? It goes back to the Scrum Mastery book; if the Scrum Team don’t hold themselves to account, and they expect the the Scrum Master to do this, it inherently drives the Scrum Team down wrong path:
- If the Dev Team don’t define their own values and rules, they generally won’t buy into anyone else’s.
- The Scrum Master is seen as a “manager” by the Scrum Team
- The Scrum Master is seen as the “bad guy” rather than an enabler and servant-leader (arguably a front “leader”, instead of a rear “leader”)
- The Scrum Team will expect the Scrum Master to deal with certain things (difficult situations), instead of dealing with them themselves
The above is also why I think having line managers managing Dev Team members fundamentally stops full self-organisation, the Scrum Master/Line Manager becomes someone who polices the rules, and deals with under-performing individuals.
Side step — let’s talk quickly about under-performing individuals
When we talk about self-organising teams dealing with under-performing individuals in the Scrum Team, some people think this means the Scrum Team has to start putting PIPs in place and talking to HR about the individual.
This is very far from what we’re trying to achieve; line management and HR still have responsibilities in an organisation, regardless of if that organisation being Agile, or using Scrum.
Ultimately this means the Scrum Team should feel comfortable about probing an individual as to why they are under-performing,and seeing if they need support (The Daily Scrum may drive some of this; “I see you’re still working on that 1 hour task, do you need any help with it?”) — Sometimes there does become a point where an individual just isn’t a fit for the Scrum Team, or is just doesn’t have the right skills — this is when a line manager should start to get involved.
Bonus — Team identity!
There is also an additional bonus when creating a Team Charter, this gives the Scrum Team an identity. Now they have a common set of rules and values to work together by, it gives the Scrum Team a sense of belonging together. If a new person joins the Scrum Team, the existing members will expect the new member to work in the same way they do — the Team Charter gives new members a way of understanding how the Scrum Team currently works.
Why the Dev Team?
The Team Charter — at least the values, expected behaviors and meeting rules part of it— is all aimed at the Dev Team, why is this? As mentioned above, you want to find what values and rules the Dev Team (“the contributors”) to work at their optimum level, plus there are more of them than there are POs and Scrum Masters.
When one person in the Dev Team is away, the rest of the Scrum Team should still follow the charter, if the Scrum Master is away and no one really bought into his/her rule(s), then no one will uphold them when he/she isn’t in.
It’s also worth saying here, this isn’t just for the Dev Team to hold themselves to account, they should also be able to hold the Scrum Master and Product Owner to account. If the Product Owner starts looking at his phone during Backlog Refinement for example, the Dev Team should feel empowered to ask the PO to put the phone down or else leave the room (as an extreme example).
How to put a Team Charter together
The session will take about 1.5 hours to run for a Scrum Team of 7.
First you’ll want to setup the board before the Scrum Team arrive in the following arrangement:
The questions on the board are:
- Top left — Team’s purpose
- Bottom left — What does success look like?
- Middle column 1 — What are the team’s values?
- Middle column 2 — What do you want from your team mates?
- Right column — What are the rules in meetings (split into: “General”, “Daily Scrum”, “Sprint Planning”, “Backlog Refinement”, “Sprint Retrospective”, “Sprint Review”)
I would recommend doing these in the following order, and time-boxing each of them; purpose, values, want from team mates, rules, success.
Team purpose (Scrum Team) — approx. 17 mins
This is perhaps one of the most complex parts of the Team Charter session — with both of my Scrum Teams, I couldn’t fully complete this, and had to take away the information.
Ask the Scrum Team to write 1 sticky note about what they think the Scrum Team’s purpose is… why did the organisation setup the Scrum Team?— this should take approx 3–5 mins.
Ask each member to come up, and stick their sticky note in the “purpose” box on the board and tell the Scrum Team their thoughts about the note — this should take approx 1 min per person (7 mins for 7 members).
With the Scrum Team, spend approx. 5 mins trying to turn all the sticky notes into a single coherent purpose for the Scrum Team.
Team values (Dev Team)— approx. 21 mins
This part of the session is more involved, but the outcome is much easier to define.
Ask each of the Dev Team to write down what their values are (the values they personally live by), they can use as many sticky notes as they like, and ideally only 1 word should go on each sticky note. You should expect to see things like; “Respect”, “Honesty”, “Trust” etc… This should only take 5 mins.
You will also need to ask each person to write their name in the corner — this step is important.
Same process as before, ask each member to come up and share their sticky notes. Try and time box this to 1 min per Dev Team member.
The next step, after everyone has put up their stick notes, it to reduce them down to the common denominators — where one or more sticky note is pretty much saying the same thing (remember, you need to get the Dev Team to agree that the sticky notes are saying the same thing! If you do this unilaterally, you may lose buy-in), the duplicated sticky notes can be removed.
Put the names from the removed sticky notes onto the remaining one on the board e.g.
Once the sticky notes have been reduced down to the common denominators, you’ll want to find out if the majority of the Dev Team agree with what has been proposed (again, if you only have 1 or 2 members of the Dev Team who agree with some of the values proposed, you won’t get full buy in).
The next stage is to start the voting process, give everyone in the Scrum Team 2 sticky dots (or a pen to apply dots) and ask them to vote on which 2 they agree with more.
However, they can’t vote on any with their name on it (since they’re likely to do this) — any with names already have a vote… 3 names = 3 votes, 1 name = 1 vote, 1 name with 2 dots = 3 votes etc…
Once everyone has voted, rank the values by number of votes (remember, names count as a vote!). Find a natural cut off (usually something like 3 or 2 — this is highly subjective and is just what “feels right”), and throw away any sticky notes below that number of votes.
Ask the Dev Team if they agree with what the results are — sometimes someone will point out something missing, but get the Dev Team as a whole to agree to put it in!
You now have a list of values which the Scrum Team can be held accountable to.
What you expect from your team mates (Dev Team)— approx. 21 mins
From the “values” part of the session, we now know what values the Dev Team would like everyone to live by. The next section is more about what behaviors they expect from the team mates — this should somewhat line up with the values (so really, you’re asking them what those values actually mean to them) — but some members may go a little off piste… which is absolutely fine!
There may also be some specific behaviors the Dev Team are looking for e.g. “take responsibility for ones own knowledge and ability”.
This part of the session can be run exactly the same as above; everyone writes as many sticky notes as they want, presents back, remove duplicates, vote, remove sticky notes with low number of votes.
Remember the “is there anything missing here” bit at the end!
Meeting Rules (Dev Team) — approx. 21 mins
This part of the session is about what rules the Scrum Team should apply to meetings and events. You can run this part largely in the same way as above the difference being the hierarchy of rules.
This section is split 6 smaller sections; “General”, “Daily Scrum”, “Sprint Planning”, “Sprint Review”, “Sprint Retrospective”, and “Backlog Refinement”.
Rules the Dev Team want applied to all meetings (all events and other meetings) go under the general heading. Specific rules for specific events go under the heading for that event, the general heading saves the Dev Team having to write the same rules under the 5 other event headings.
Anything under “general” is also superseded by anything under an event heading. For example, the Dev Team may say “everyone must turn up on time” under general, but then for Backlog Refinement they might say (for some very very strange reason), “people can turn up late”. The late rule would override the on-time rule specifically for that event.
When voting, all rules across all subheadings get voted on together, and the cut off applies to all subheadings too. So for example, someone may have given a specific rule for Daily Scrum, but everyone else felt the rules under general are ones they agree to more. And thus it receives no votes and is removed.
There is a caveat to the paragraph above — when I ran this session for two of my teams, only 1 person in 1 team applied an event specific rule. If when you run this session you find there are more event specific rules than general ones, you may wish to tweak this part and do separate voting sessions for each sub heading.
Defining success (Scrum Team) — approx. 15 mins
This part of the session is by far the easiest, just ask each member of the Scrum Team what 2 things would define success for the entire team. Each person in the Scrum Team writes 2 sticky notes, and presents them back to the team.
After everyone has put up their sticky notes, remove the duplicates (remember to check with the Scrum Team as you remove each duplicate).
Once all duplicates are moved, that’s the session finished!
After collating all of this information, it’s worth turning it into something which presents nicely on the wall — this gives the team something to refer to, and also shows that this is something the Scrum Master is serious about and wants to invest in.
I personally turned mine into a scroll (well, it will be a scroll when the scroll ends arrive!)
As well as having a copy of the charter on the wall, it’s also worth distributing a laminated A5 copy to all team members, so they can be reminded what they bought into in all meetings.
The final step to cement the final level of buy-in and accountability is to get the whole Scrum Team to put their signatures at the bottom of the charter.
Try out Team Charter sessions with your own teams, and let me know how it goes in the comment section!