Hello, Dennis Rios here again. Sometime in the last few sprints, we recognized that in order to continue building the next generation of our products and services, we really needed to hash out some rules to help keep us moving in the right direction. So, last week the Development team, along with our ScrumMaster, carved out a few hours and worked out a set of rules and guidelines, or “ground rules.” In this week's post, I am going to spend some time talking about the value of ground rules (on and off the Dev team)!
Ground rules, a.k.a. working agreements, are guidelines developed by the team on how to cooperate together in order to create a positive outcome. They often contain a set of acceptable and unacceptable behaviors from team members. The purpose of these guidelines is to establish a "one team" culture.
Picture ground rules like the rules of a new board game. You don’t just start throwing the dice without having a clear understanding of the rules. Especially if you have highly competitive friends in the room! At least not if you want to maintain those friendships. Right? You read the rules and make sure everyone agrees to them. Once you start playing, you keep those rules handy because you know that at some point you are gonna have to remind the group (probably more than once) of the rules everyone agreed to at the beginning.
Last night a couple of friends got together for a night of board games. During an intense round, a discussion ensued over who was winning. After some back and forth I decided to intervene and utilize my newly acquired “ground rules” knowledge. I suggested we stop arguing, read the instructions and have everyone agree on what rules to follow. Simple enough right? Agreeing to follow a set of rules allowed us to enjoy the rest of the evening and save a couple of long lasting friendships.
Ground rules are generally discussed and agreed upon at the beginning of a project by the Dev team. The ScrumMaster generally helps facilitate this meeting and encourages team members to follow these rules. Once the ground rules are agreed upon and drafted, they should be posted in a visible place so team members can immediately point out rule violations. Here are some examples:
- Show respect
- Don’t interrupt
- It's ok to disagree
- No personal attacks
- Have an agenda
- Be on time
- Everyone participates
- Everyone is heard
- We make decisions as a team
Establishing these guidelines from the start enables the team to talk about difficult topics and have challenging conversations. Other benefits of ground rules include:
- Establishes a "one team" culture
- Creating shared responsibility
- Enhancing the group process
- Empowering the ScrumMaster to lead
Ground rules work best when they are:
- Important to the team
- Limited in number
- Supported by all members
Although we did not develop these rules at the beginning, creating these after a couple of sprints enabled us to be a bit more thorough and specific. Why? Because we were already experiencing a couple of issues with long stories, unclear criteria, etc. After receiving some guidance from the ScrumMaster and sharing different concerns and difficulties, our Development team was able to come up with the following list of ground rules:
- Start on time, stay on time, end on time
- Don’t ignore usability/UX issues
- Respect other’s time and thoughts
- Keep stories short and ask for clarification
- Report impediments ASAP
- Be realistic about availability and story points
- All team members are created equal
For the "authentic" version of the Dev team's ground rules, check out the photo above. (Er...ignore that scrawl on #7) These were not all the rules that were discussed, but they were the most important ones and the ones that every team member agreed to follow. These rules are never done, they should be revised and updated continuously as the needs of the team change.
Ground rules may sometimes appear to be basic or obvious, but they are often not observed when they aren't written down. Creating a set of rules and guidelines will improve communication between team members, in turn improving workflows and, ultimately, the end product.