The ways of working (WoW) manifesto, also known as a working agreement, consists of a set of guidelines or behaviours that a team has agreed upon to define how they want to work together. This agreement is crucial for the team to collaborate effectively as it outlines the expectations for each team member. For example, it describes the Agile processes (standup, refinement, retrospective, etc.) or delivery guidelines (pull request review, code style, documentation, WIP limit, etc.).

Why do we need the WoW manifesto?

In a collaborative environment, each individual has preferences in working and processes, which often don’t match up by default. This misalignment ultimately leads to poor performance since everyone has different expectations and processes.

The working agreement aims to agile the team collaboration and highlights the following benefits:

• Aligning the team expectations - Everyone on the team clearly understands the work processes and the definition of done.
• Shared responsibility and ownership - The team agreed on how to work, which builds trust and shares the responsibility of keeping high standards.
• Increase the team productivity - The team is aligned and follows the same processes, which removes wasteful conversations and energy, ultimately enhancing the team’s productivity.
• Onboarding new joiners - The WoW manifesto helps speed up onboarding new joiners since they can read the manifesto and quickly be aligned with the team.

How do you create a working agreement?

The first step to creating a working agreement is to decide as a team what agreements they should include for the team to function. It is vital to include the whole team in the process to ensure everyone has the opportunity to share their thoughts and create a consensus.

Since every team is unique, there isn’t a single list that works for every team, but you can use the following list as a guideline:

• Roles
• Agile Processes
• Measuring Success
• Learning Time
• Code Styles
• Documentation
• Communication
• Pull Request Review Practices

Good Practices

• The working agreement must be a living document and updated to reflect the actual processes.
• Keep the working agreement in a single place as part of the team’s documentation.
• It is mandatory to create a working agreement with the agreement of the whole team. It can be tempting to copy it from a previous team or workplace, but that won’t work because each team is unique. The entire team must be part of the definition of the working agreement.
• The most efficient way to ensure the agreements are consistently followed is to automate them. For example, you can use the CI/CD pipeline to validate code style and quality checks to avoid unnecessary conversations during code reviews.
• To facilitate writing the agreement list, you should follow the format: “As a team, we agree to …” to give more sense of shared responsibility. For example: “As a team, we agree the maximum work in progress (WIP) is N (where N is the number of team members).
• Create a process to facilitate proposing changes to set higher standards. All changes must be agreed with the team to keep the consensus.

Example of a working agreement

Agile Processes

As a team, we agree…

• to follow the SCRUM framework.
• the role of SCRUM master rotates every sprint.
• to avoid meetings during the afternoon to maximise engineering deep work.
• each sprint must have a duration of two weeks.
• each sprint must have a clear goal.
• another ticket must be removed from the sprint to keep the team’s velocity if an urgent ticket comes to the sprint.
• when pulling an unplanned ticket to the sprint, we must label it with unplanned_work.
• the maximum work in progress (WIP) must be N, where N is the number of people in the team.
• tickets are organised by priority in the TODO column.
• all tickets must be refined to be pulled to a sprint.
• a complex ticket should be paired with another engineer.
• when a ticked is more complicated than expected, it should go back to the backlog and be broken down in the next refinement session.
• ticket is only DONE when it meets the definition of done (DoD).
• the team velocity is only used for the predictability of the sprint planning.
• the team velocity is unique and must not be compared with other teams.

Standup

The standup is a daily meeting where the team shares updates about what they did yesterday, their plan to work today, and share blockers.

As a team, we agree…

• to meet for the standup meeting every day at 9:30 AM (GMT+1).
• every team member has a maximum of two minutes to give the updates. It will be discussed in a separate meeting if they need more time.
• the standup must last a maximum of 15 minutes.
• the standup is crucial to share individual updates and be aware of what team members are working on.

Refinement

The refinement session aims to prioritise, review and clarify the tickets in the backlog. During the session, the team prioritises the tickets, ordering them by priority (top high priority), ensuring everyone agrees with the definition of ready and estimates the effort to complete the ticket.

As a team, we agree…

• a ticket is refined only if it meets the definition of ready.
• to meet for the refinement session weekly on Thursday at 10:00 AM (GMT+1).
• the refinement session has a duration of 60 minutes.
• bugs are not estimated due to the unpredictability of the effort.
• spikes are not estimated but time boxed in days.
• to estimate the effort of the work, we use the Fibonacci sequence.
• everyone understands the acceptance criteria.
• if the estimation of effort is higher than 5, the ticket must be broken into smaller tickets.
• if the ticket is unclear, we assign a responsible person to look for clarification and discuss it in the next refinement session.
• if the solution needs to be clarified, we create a spike to investigate the solution.

Review

The review session happens right before the ending the sprint. The goal is to review the status of any pending work and understand if the team met the sprint goal and the progress towards the quarterly OKRs. After closing the sprint, it is essential to compare the team metrics, such as velocity and cycle time to the previous sprints to understand if there was any disruption.

As a team, we agree…

• to meet for the review session every two weeks on Wednesday at 10:00 AM (GMT+1).
• the review session has a duration of 30 minutes.
• to review the pending work and explain what is missing and why we couldn’t complete it.
• to review the team’s progress to meet the quarterly OKRs.
• to discuss if the team met the sprint goal.
• to review the team metrics and compare them to the previous sprints to understand if there were any disruptions.

Planning

The planning session marks the start of a new sprint. During this meeting, the team agrees on what work the team should focus on during the next two weeks.

As a team, we agree…

• to meet for the planning session every two weeks on Wednesday at 10:30 AM (GMT+1).
• the sprint session has a duration of 30 minutes.
• the team must define the sprint goal.
• to have a 10-20% buffer to work on technical debt.
• the amount of work for the sprint must not be superior to the team’s velocity.

Retrospective

The retrospective session is when the team reflects on the sprint performance. It is the time to celebrate the success (What we did well), the challenges (What we didn’t do well, and potential improvements (What we should start doing). The whole team must reflect on how they did in the sprint and look for opportunities to improve as a team.

As a team, we agree…

• to meet for the retrospective session every two weeks on Thursdays at 11:00 AM (GMT+1).
• the review retrospective has a duration of 60 minutes.
• the facilitator creates the Retrium or Miro board with the following format: What did we do well? What could we have done better? What should we start doing?
• to discuss the topics and create the following action items to improve as a team.
• each action item must be clear and have a deadline and an owner.
• to review the action items from the previous session.

Definition of Done

The definition of done (DoD) is vital to ensure everyone is aligned with the requirements to complete a ticket and move it to the DONE column.

As a team, we agree…

• the acceptance criteria are met.
• to write unit, integration and E2E tests.
• the PR needs to be reviewed and approved by at least another engineer from the team.
• the PR must pass all the CI/CD pipeline checks.
• to deploy in the development environment and test.
• the observability must cover the changes. e.g. metrics, logs, traces.
• to update the relevant documentation related to the work. e.g. public API specification, ADRs.
• to update the relevant stakeholders and dependent teams.
• to monitor the deployment for medium/high-risk changes.
• to run the E2E tests in production after deploying the changes.

Definition of Ready

The definition of ready is an agreement between the team that a ticket is ready to go from the backlog to the sprint. During the refinement session, the team reviews the tickets with high priority and refines them to ensure they are clear and have all the required information to be completed.

As a team, we agree…

• the title is descriptive.
• the ticket has a clear description.
• the ticket contains relevant links to documentation.
• the ticket contains test scenarios.
• the ticket has clear acceptance criteria.
• the ticket must have the right type (story, bug, spike, tech debt, KTLO).
• the ticket is linked to an epic.
• the ticket needs to have an estimation.
• the ticket needs to have the correct labels.
• the ticket needs to have the risk level.

Learning Time

Every team member is entitled to 10% of learning time per week. During this time, it is expected to work exclusively on personal growth. This work might include following a training course, preparing presentations, contributing to guild initiatives, learning more about the product, etc.

As a team, we agree…

• every Friday afternoon is dedicated to learning time.
• no meetings on Friday.
• to avoid doing sprint work during the learning time.
• to talk with the engineering manager if we feel pressure with the workload.

Communication

Documentation

We use Notion to keep track of the team’s documentation. The team’s main page should be clean and include only the main links to sub-topics (e.g. runbooks, team metrics, OKRs, Projects).

As a team, we agree…

• use Notion for all the written documentation.
• to keep the team’s main page clean and have sub-links to the topics.
• to be specific, accurate, and concise and ask for the review before sharing it broadly.
• to be responsible for keeping the documentation updated.
• to create technical and product briefs for each project.
• to write an architectural decision record (ADR) when implementing complex features.
• each document must have a header section with the owner, status and date.

Slack Manners

The primary tool for asynchronous communication is Slack. We have the following team channels:

• ask-indigo - public channel where people from the organisation can ask any questions.
• indigo-eng - private channel for the engineers to discuss technical work and ask for code reviews.
• indigo - private channel for the entire team: engineers, designers, product

As a team, we agree…

• to avoid using @here to get attention.
• to avoid tagging people @username except in urgent conversations.
• to check Slack every few hours to catch up with relevant conversations.
• to hide the preview from shared links to avoid bloating the experience.
• always include the topic’s context to facilitate asynchronous communication and remove wasteful iterations. e.g. avoid messages that simply say, “hello X, how are you?“
• to be aware of using inclusive and friendly language.

Measuring Success

As a team, we are working towards a goal and a vision. To measure the success of the team’s work, we agree to track the product, operational and team metrics to understand if we are focusing on the right things. These metrics should be reviewed monthly with the company stakeholders to view the team’s historical progress.

As a team, we agree to track the following metrics…

Team Metrics

• Velocity: total team effort of tickets completed during a two-week sprint.
• Cycle Time: average time to complete a ticket from moving it to In Progress to DONE.
• % Scope Creep: Percentage of unplanned work pulled to the sprint.
• Business Impact: Percentage of time the team spends on each type of work. e.g. 10% bugs, 20% technical debt, 70% stories.
• % KTLO: Percentage of reactive maintenance (corrective + adaptive) of the total team effort produced over a given timeframe.

Product Metrics

• Success rate: percentage of requested payments that were initiated successfully on the provider side (did not fail authorisation, get rejected, or expire), expected to be close to 100%
• Conversion Rate: percentage of requested payments that were “executed” successfully.
• Total Payments Volume: the volume of payments

Operational Metrics

• Service availability: services must respect the SLA of 99.9% availability.
  • The availability is calculated by Service Availability = (Successful Requests) / (Total Requests - Invalid Requests - External Dependency Errors)
• Service latency contribution: services must have a p99 latency < 150ms.
  • The latency is calculated by Service Request Duration - External Dependency Latency.
• Service Maturity: all production services comply with the company’s quality standards. The services must have alerts, defined ownership, no high or critical security vulnerabilities etc.
• Infrastructure Costs: each team needs to report their infrastructure costs (MQ, Databases, VMs, Containers) to keep track of their costs over time and ensure it does not go above the team budget.
• Incidents: the number of incidents and respective impact.

Cross-Team Initiatives

A recurrent challenge when collaborating with different teams is to align expectations and set processes for both teams to collaborate efficiently and reduce the waiting time for the other team dependencies. Defining a working agreement between teams can help mitigate this problem.

As a team, we agree …

• to create a dedicated channel to centralise communication and update all the stakeholders.
• set up a weekly meeting on Monday at 9 AM to report the project’s status.
• on a pull request strategy between teams to avoid long waiting times for a review.
• to nominate an engineer from each team to act as a point of contact and domain expert.