With many software development companies mandating a Work From Home (WFH) policy, the question naturally arises, “Are my teams ready to WFH?”
Changing team dynamics is no easy feat.
Whether you’re adding new people to your team or forming a new one altogether, unpredictable dynamics can take place and create tension or even toxicity if not dealt with early. No matter how great your managing style is, there is no way you can entirely predict the possible outcomes to different team interactions. This can make it difficult to determine whether a work-from-home policy can work for your team.
The good old fashioned approach to managing is usually command-and-control, where a team is told how to act and behave by a manager. The drawbacks of this approach is that it isn’t flexible in different situations when teams are remote, out on a business trip, or working from home.
From my own experience, I’ve found that giving the team autonomy while creating guidelines that allow them to self-manage is one of the most effective ways for teams to deliver on their objectives, no matter the circumstance. It’s then the responsibility of the manager to communicate clear deadlines and targets, and check if they’re being met.
So, how do we help team members self-manage?
We do this through a working agreement.
What is a working agreement?
A working agreement is a lean breakdown that serves to set team day-to-day interactions, behaviour and overall culture. It should be visibly posted to remind the team of what they agreed on, and to serve as a transparent document that members of your organization can view as well.
Team working agreements can be formed when certain team dynamics change such as implementing a WFH policy, or even when a team forms for the first time.
At this early stage it can include things like:
- General behavior (e.g. respect).
- Punctuality, time of your daily standup or scrum, start times and deadlines for days sprints, etc.
- Leaves of absence (when to inform teams about vacation plans, sick days and personal days off).
- Online overlap time.
- Zoom/Virtual meeting behavior (e.g. cameras on, dial-in time).
Other things that need to be considered include time allotment for meetings, education and self-improvement; how/when to use tools for remote work (e.g. Slack is always on from 9 a.m – 5:00 p.m.); conflict-resolution; and alone-time versus pair-programming time.
In my experience, I’ve also learned that instead of trying to be proactive, it’s better to let problems surface, and then agree on how to avert them in the future. This is to prevent overthinking issues that may not even happen. Resolved issues are noted and the decision is documented in the working agreement for future reference.
Negotiating the right information to include
The Technical Lead or Scrum Master should create the first draft of the working agreement in consultation with their team. In this capacity, the Technical Lead is guiding negotiations, and the working team should be making changes through their retrospective exercises and processes.
Getting the working agreement right
Team retrospective meetings can ensure a working agreement is updated regularly and maintains relevance.
A retro should ideally be scheduled weekly in your first couple of weeks, just to get your team into the groove of things, and bi-weekly after that.
There are generally two types of outputs from discussing the current working agreement during a retro:
- Action items: Things that need to be done during the next sprint from a project delivery perspective (e.g. setup the CI, refactor, research spikes).
- Obstacles: These may pertain to specific projects or even team behaviour (e.g. how the team should behave within itself and with other teams if friction arises).
So what’s a good example of a working agreement retro in the works?
Okay: “Hey Alex, the team agreed that the daily is at 10 a.m. and no one would be more than two minutes late without letting the team know. But today you missed the daily again, without notice.”
Great: “Hey team, we agreed that the daily is at 10 a.m. and no one would be more than two minutes late without letting the team know. But today some team members missed the daily, without notice. Should we better enforce working agreement decisions, or should we change our working agreement?”
Keep it concise
Now, if the working agreement grows each time something is decided during a team retro, it can quickly grow into an employee guide – a long, boring, bureaucratic document that no one reads or truly abides by. This undermines the goal of creating a culture where the team enforces its own decisions.
Therefore, once the team adopts the behavior agreed upon, the items that may be deemed common knowledge at a certain point can be removed from the working agreement during the retro, so that it never includes more than four to five items. It should be more of a reminder of bad habits that the team finds difficult to quit, rather than a collection of retro minutes.
Example: “Team, I’ve noticed that since our last retro, when we decided not to use the f- word, not a single f-word has been spoken out loud. So I’m going to remove it from the working agreement, okay?”
Generally, I’ve found that when you discuss problems during a retro, teams are often open to changing their behavior, without even having to write it down in the agreement.
Working agreements are mainly created to help teams realize there’s no one holding the whip when they’re working remotely, so they need to enforce their own decisions that are facilitated by the Technical Lead or Scrum Master. They have helped me form numerous teams that can adapt to rapid change while still delivering on items productively and efficiently. And if you hope to achieve lean remote team management, a working agreement can be a powerful tool in any leaders’ arsenal.