How to create a ways of working agreement

An edited version of this post is available at https://leaddev.com/process/how-create-ways-working-agreement

A ways of working (WOW) agreement assures that all members in your team understand intra-team and inter-team processes and roles.

In small teams, it’s easy enough to announce ad hoc who will do what. But as an org scales, roles become specialized. In these cases, it is essential to have a more detailed outline of expectations. Having a formally written WOW agreement will help in several ways, including:

• Allowing newly onboarded members to clearly understand processes and role parameters, without any ambiguity or second-guessing.
• Providing a framework to define how work flows through the team.
• Delineating responsibilities, expectations, and priorities to reduce overlap and gaps.

No two WOW agreements will look the same, but there are core elements that teams should strive to include.

How a ways of working document benefits onboarding

When an employee is onboarded, the goal is to integrate the new member so they can become productive as quickly as possible. A WOW document achieves this by helping new members understand the day-to-day operations of a team.

The existence of a WOW agreement can make or break a new member's first few weeks at an org. In one of my previous roles, I joined a company that had no onboarding process. I was assigned an onboarding buddy. They were friendly, but I was expected to figure out how to make myself useful. I felt very much like an outsider and had trouble understanding how I could provide value.

I spent my first few weeks shadowing people, asking questions, and recording my findings in the hope that the resulting document would provide some guidance for the next hire to follow. Overall, the lack of any formal guidance impeded the time it took me to acclimate to my role.

By contrast, I experienced onboarding in another role where the practice was more mature. There was a checklist to ensure meetings, rituals, and team processes were explained. I was systematically invited to each meeting as they were explained. I was also scheduled to meet different members of the team who explained the processes the team follows and where to find resources to learn more. I was a lot more comfortable with this process and felt immediately included by the first week.

I’ve outlined some guiding pointers for what you should consider including to address onboarding:

• Team rituals
  • Clearly define the cadence of standups, kickoffs, and retrospectives to allow team members to plan their calendars accordingly. If there’s a rotating roster, let people know when they’re scheduled to be hosting.
  • Make sure to send all the requisite meeting invites to new joiners, highlighting which are required and optional to avoid confusion.
  • Be specific in how your team/company defines hybrid working to ensure everyone is on the same page regarding cadence and format of team lunches, in-office days, or social sessions.
• Collaboration
  • One of the hardest problems facing teams is deciding on their documentation system. Where should members look for answers e.g. slack, confluence, GitHub issues? Knowing this allows teams to self service and answer questions faster.
  • Where are cross-team collaborations tracked? For example, does your team use an online whiteboard or a specific file sharing service? Having a standard approach to record keeping helps establish a source of truth to reduce ambiguity and increase clarity.
  • Different team members have preferences on how they collaborate. Find out their preferences and understand how the team communicates and what methods members use to support each other.

Using a ways of working agreement to understand how work flows through the team

A WOW document should have a section defining the process for bringing work into a team and getting it done. Engineers, delivery leads, and product managers should sit down and walk through the workflow to ensure everyone understands the expectations. The broad questions that these discussions should be able to answer are: how does work get into the backlog, and how is it processed to leave that queue?

For product teams, the product manager is usually the role that engages with customers/stakeholders to define the roadmap at a high level. This roadmap gets broken down into smaller epics that form the team’s backlog. A lead developer or a business analyst might refine the requirements as the work gets divided and evolves. When interfacing with product, there are some foundational aspects that need to be aligned on. Such as:

• What constitutes “ready for development,” and who makes the call? A clear definition of what makes a piece of work ready helps the team separate the things that need more discussion from what’s ready to be completed.
• Is there an agreement on the estimation process? Having an explicit consistency or effort-based estimation agreement will ensure everyone feels heard and allows for proper planning.
• How is work prioritized within a sprint or release cycle? Normally, a team’s sprint will comprise mostly planned work around product or strategic initiatives. However, unplanned work, such as support requests and bug fixes, must also be addressed. Does the team have a clear approach to prioritizing unplanned work into a sprint?

If there’s friction between the two teams, it is worthwhile to have engineers and product sit down together to discuss their perspectives. Some questions to consider when finding a middle ground:

• How much agency do developers have in finding a solution? How much time should they spend investigating options, and when should they escalate the problem if a solution is not found? The team needs to be aligned on the priority between delivery and learning – sometimes a quick solution is needed, but too much pressure on delivery can cause burnout and decrease job satisfaction.
• What testing needs to be done? What constitutes testing needs to be defined at a team or institutional level – no standard works for all teams across all industries. For instance, some teams will require QA steps prior to production deployment whereas other teams might only test in production via canary deployment. It’s important to weigh the risks versus the effort involved. Proper risk management requires alignment and standards of risk levels and proportionate precautions.
• What frameworks are used to make decisions, resolve conflicts, and handle exceptions? Having an explicit decision framework will greatly increase the speed by which decisions are made and avoids confusion over what to do next.

Aligning on these facets helps a WOW agreement clarify expectations on how engineers should make decisions when working on a product.

Delineating responsibilities

Many people join a team having a vague understanding of expectations, either from having read the job description or holding preconceived notions derived from past roles – or both. However, these factors may be misleading. A true understanding of the role comes from answering these two questions: what tasks or areas is each person in my team responsible for (who is doing the work), and who is accountable for the outcomes (who is making sure the work is done correctly)

When there’s less ambiguity on role remits, there are fewer opportunities for misunderstanding and friction. Despite most tech companies having similar-sounding role titles, the responsibilities can vary across teams. For example, some teams will only consider seniors for feature/slice leading and will have a dedicated scrum master who oversees all ceremonies, while others will distribute the roles on a rotating basis.

When outlining remits, the team should take care not to be too specific. It can discourage growth if individuals are boxed in by impermeable boundaries they’re not allowed to stray beyond. It could also make the team very brittle if certain responsibilities are only covered by one role. For instance, if a tech lead is the only one allowed to make all tech decisions, teams will easily become blocked if said tech lead is unavailable. For this reason, it’s best if there are backup mechanisms or ways to delegate established in the WOW agreement.

Knowing your boundaries

As a leader, it’s imperative that you have a good grasp of what normally goes on within your team – this will help with unifying people’s understanding of their own responsibilities. If you have multi-team initiatives, it may also be wise to consider creating a WOW document focused on understanding the boundaries between each team. For instance, having clear system ownership boundaries can increase the speed of delivery. Each team can focus on testing within their own systems, and inter-system dependencies can be clearly defined and tested via contracts.

As the seniority of your role increases, the amount of responsibility and ambiguity also increases. Gergely Orosz details some of the role distinctions in engineering leadership and how responsibilities and skills can overlap. For example, in some organizations, a head of product is responsible for delivery timelines and project budgeting. Should an engineering manager be praised or reprimanded if they took the initiative to discuss ways to reduce the scope or make changes to the release schedule? The answer is probably situational. As a leader, it’s important to understand what your core responsibilities are and where you can optionally expand your influence.

Key points to consider when outlining roles in a WOW agreement:

• Describe the current state. Is there a consensus on what everyone is doing?
• What distinct roles are there within the team? What are the priorities of each role, and how is success measured within it? You may not be able to name everything each role does, but you should still be able to prioritize the responsibilities – what are they?
• If there are any absences, who is covering the gaps?

Final thoughts

By documenting processes, roles, and responsibilities of a team in a WOW agreement, onboarding new members becomes easier, workflows gain more clarity, and members understand their roles better.