In my previous posts, I talked about both values and goals. Both are useful, but goals without underlying values leave people feeling hollow. This feeling is regularly felt by development teams where the only focus is task completion with no concern, or only lip-service to quality, mentoring, honesty, and so on. My last post detailed a workshop to get in touch with your personal values. In this post, I’m going to continue the workshop by helping development teams weave values into the process.
On a recent contract, I remembered having the distinct feeling that the team was operating in an organic way. Not the meaningless kind of “organic” thrown on snacks by commercial farms these days–but a truly natural and mostly harmonious manner of working. The contract ended and I had time to reflect on what key elements led to our team creating the culture it did. I concluded that our reliance upon and commitment to working according to our team’s working agreement led to much of the success in our dynamic. The essential components of a team working agreement are the team’s values.
Our working agreement had several sections that included general agreements, meeting agreements, software development agreements and more. Each section focused on the important contracts we needed to make with each other so that we could function at a high level. Everyone contributed to the bullet-points that made up each section and we decided as a group to adopt or reject them. When new team members came in we would review the working agreement. Not only did this give the new team member an orientation to our way of working and allow them to alter it, but it also refreshed our minds as to what we found important to our team. Each person on the team largely internalized the exercise and brought that to work each day since everyone had input and therefore had an incentive for the working agreement to live in our interactions and efforts.
For the most part, management didn’t interfere in our working agreement process or try to influence it. Their hands-off approach was critical. Any seeming corruption of the working agreement by those in-charge would diminish the desire of the team to truly adopt it because it would no longer be “our” working agreement; it would be slightly more “their” working agreement.
How to build the team working agreement
The team working agreement workshop begins by everyone taking sticky notes and writing down the values they would like the team to operate under. When everyone is finished, each person takes their stickies and puts them on the wall. If someone sees their value, or a very similar value on the wall, they place their sticky next to it. For example, if I have a sticky that says “truthfulness,” and “honesty” is already on the wall, I place my sticky next to it.
When everyone is finished there will be clusters of values on the wall. The biggest clusters are the values that the team cares about the most. These are the values that will be focused on in the next part of the workshop. The values that only came up once or twice shouldn’t be completely neglected or thought of as unimportant. Just like in the individual workshop, people can come up with a long list of helpful values, but only a few can realistically be focused on, otherwise the entire exercise gets watered down with too many concepts.
In the next part of the workshop, everyone gets to participate in another round of team agreement creation. Keeping the team’s biggest values in mind, everyone will write down values-driven behaviors they would like the team to engage in. Once everyone has written down three to five things (or one if you have a team bigger than six or seven developers), each person will again place their stickies on the wall next to the value cluster that they feel most represents that particular sticky. For example, if a team value is “quality” and my sticky says “fix broken build/bugs/tests before adding features,” I will place it next the “quality” stickies.
Once everyone has placed their stickies on the wall, the entire team can see a set of actions and behaviors that team members care about and align with the team’s values. Take it all in–your team has come a long way toward deciding what kind of values will drive the team and defining behaviors required to fulfill those values.
The final part of the workshop involved someone projecting their screen and putting all of the team agreements into a document, wiki page, web page, or whatever format your team will find most useful. Be creative and do what works. There’s no right way. Once all of the team member’s ideas have been captured there is a final vetting process. By default, everyone’s ideas get included. Now have someone read out each idea one at a time. Only if there is team consensus that an idea isn’t a good fit for the team should it be taken out of the team working agreement. Once the process is complete, your team should have twenty or so items in your team agreement that spell out very specific ways that team agrees it will work. Your team has now made a working agreement according to its unique philosophy and values.
Once the agreement is in place, your team will need to identify any missing resources required to let your team function according to your values. If you don’t have a CI server, for example, and your working agreement requires one, efforts will need to be made to make that happen. Once the team has made a punch-list of required resources, the team will need to negotiate with whoever is responsible for obtaining them.
The most important actions come after creating the team agreement
What goes in the working agreement is far less important that how the working agreement is maintained. My team fostered the working agreement and referenced it regularly in our interactions, especially in retros. Our retros were, in fact, reviews of how well we worked according to our agreement. This can’t be emphasized enough. A working agreement isn’t a new concept, but fostering it and developing it like a child is the part that is often overlooked. It must be brought to life and that requires effort. Usually one person will light the torch and take it seriously enough to keeping blowing air on the embers. But unless a second person, and a third, and eventually all team members take turns helping it to become real, the team working agreement will be just another stupid page on the wiki.
A team working agreement has another benefit–it’s far easier to give criticism in a way that doesn’t come across as personal. If someone leaves without fixing a broken build, if “don’t leave without making certain your check-in doesn’t break the build,” is part of the team agreement, it’s very easy to say, “Hey, our working agreement says not to leave without making certain your check-in passes.” People receiving criticism around the working agreement being broken are less likely to feel singled out or picked-on. They helped create the shared culture of the team and so criticism isn’t just someone’s personal taste.
A team working agreement doesn’t solve all problems. People can still be assholes. Managers can still ask for things that violate the working agreement. Many interactions and individual actions will occur that aren’t in-line with the team working agreement. However, it’s far better to strive for the ideal, knowing it will never be reached, than to have no ideal at all. The team working agreement is an anchor in some circumstances and at other times a beacon that points the way forward. Use your working agreement often and without hesitation.
In the final post in this series, I will tie together all of these workshops and concepts and attempt to paint a picture of what agile with values looks like in real life.
Ian Felton – The Psychologist Coder
P.S. Here are examples from my team that your team can borrow from if you’re having a tough time coming up with things
No hit-and-run sprint planning: All team members should be confident in story requirements and acceptance criteria if they may be expected to work on the story.
Have a good understanding of what we are solving and who the audience is. Don’t leave backlog meetings confused about this.
This is a safe-to-fail environment.
Tell the truth. Accurately assess task status. Bad news doesn’t get better with age. Accurately estimate tasks even if it means displeasing people. Don’t feed people the answer they/you want to hear.
We succeed or fail as a team. Pay attention to the entire body of work for the sprint and not just the stories assigned to you. If you notice somebody struggling with a story or heading down the wrong path, ask if they need help rather than just watching them fail. Completing the whole sprint is a team responsibility.
Get explicit, non-coerced agreement on decisions. Voice dissent rather than silently disagreeing.
Commits and pushes to the origin feature branch should be small and frequent. If you wouldn’t give up CTRL+Z, you shouldn’t be committing only when you’re finished with a task.
Fix failing tests. Do not comment out or delete. Do not reduce code coverage thresholds.
To do comments should always reference a JIRA story code that explains the work to be done.
Technical stability over strong opinions (introducing new tools and frameworks are a last resort).
If the sprint is finishing early, pull any critical or blocker items from the backlog first, otherwise pull from the tech debt epic.
Maximize our existing tools before creating one-off processes or adding additional tools.
Merge or decline any outstanding pull requests before creating any new ones of your own.
Plan ahead and leave everything in a good state before stopping work or moving off-site. This includes making certain that all pull requests are merged or declined and builds succeed as well as closing the loop on any outstanding communication.
P.P.S. If you’d like me to come in and help you with agile with values with one of your teams, contact me.