We talk a lot about how assumptions in business can kill you. But assumptions on a team can do the same. One of the best way to preserve a transparent, low-politics culture is to keep everything as visible and explicit as possible. This applies to strategy, vision, and values, but also to working methods.
We were forced to deal with the latter at Neo (acquired by Pivotal in January) because we had new teams constantly coming together, both in terms of mixing new employees with old and also embedding client employees in our teams. While we had strong principles around lean and agile, we did not believe in being prescriptive around tactics. We asked our teams to customize their tactics for their specific context, stage and need. If one team did retros every third week and another needed them every week, that was fine. If one team wanted to pair program all the time, and another did so only occasionally, that was fine. Excellent work and progress towards goals were the things that mattered, not dogmatism over the details.
But while it seemed like everyone spoke the same language, we quickly found that in the weeds of those details, expectations were different and people would get frustrated or disappointed with each other.
Our general approach to confusion was to shed light on it. However, the solution here was not to create a prescriptive playbook. Instead, we implemented written team working agreements that covered working methods such as agile flavor, recurring meetings, working hours overlap, story writing and prioritization responsibilities, work in process limits, coding/testing/deploying responsibilities, etc. Every time a new team was brought together, they were required to talk through the document and agree on the items. The document was stored in a public place and the team was asked to periodically revisit it, especially if retros were showing signs of strain.
A first team meeting covering the document could easily take an hour, but the exercise of talking things over was critical. Mid-project checkins on the document usually only took a few minutes.
We tried it on one team, and then rolled it out for all teams and made it a requirement. The results were pretty instantaneous. While it did not solve all personnel issues, avoidable complaints deriving from miscommunication and missed expectations dropped significantly.
We (it was a group effort) created two templates. One was for “production” projects where we were building and deploying a real product, and the other for super-early-stage projects where we were testing out an idea. Process needs are different in those contexts.
I’ve shared an example of the “production” team working agreement on Google docs.
I want to stress that while the templates had defaults, it was up to the team to decide on their specifics. They just had to align as a team.
I do not think that these agreements are necessary in all cases, but you might find them useful if you fit any of these scenarios:
1. Your team is geographically distributed
2. Your teams are having unnecessary misunderstandings or process debates between the roles
3. Your teams are changing a lot due to personnel growth, churn or other causes.