Working Agreement 3.0

Introduction

This document outlines the principles and behaviors that guide our interactions and collaborations. It serves as a guide for our team to ensure we are working together effectively and efficiently.

Agile

• We always start project with a kickoff meeting, where we provide clarity around business needs, bigger picture, domain, roles and responsibilities of each team member and document them in outline.🚀🚀
• We make sure that all team member of project are getting first hand knowledge directly from client.👨🏻‍💻
• We keep our tickets (Story, Task, Status) up to date, at any given time any external or internal stakeholder should be able to discern whole picture by looking at board.🎟

Up-to-date tickets

Maintaining up-to-date tickets is of paramount importance, as the task tracking board serves as the definitive source of information. A quick glance at the board provides an immediate overview of our progress. Furthermore, this practice greatly enhances asynchronous communication.

• We create stories with clear acceptance criteria so it clarifies the expected outcome(s) of a user story in a concrete manner.💬
• We determine story points by considering the level of effort needed, the time required, and the complexity of the task at hand. ⏰
• We adhere to Agile rituals such as backlog grooming, sprint planning, daily scrum meetings, and retrospective meetings. 🤝🏻

Crucial Meetings

While all meetings hold significance, it is particularly crucial to conduct daily scrum meetings and retrospective meetings comprehensively. The daily scrum offers the entire team updates and insights into our current cycle’s performance and direction. On the other hand, retrospective meetings furnish us with valuable learning opportunities and actionable feedback, highlighting areas that require improvement or where we may have faced challenges.

• We hold internal demos a day prior to the client presentation to ensure our readiness and to minimize any unexpected developments during the actual client meeting.🤞

Behaviors

• We care about business outcomes. We care about business outcomes. We care about business outcomes. 🤌🤌🤌
• We show all team members equal respect.💪
• We care about work life balance and if we have to work overtime to meet deadlines then we realize that something has gone horribly wrong. ☀️⭐
• We work as one team and strive towards clear inputs (Scope, Acceptance criteria, DOD etc) and plan rigorously before accepting or starting new work.🤔
• We go out of our way to explicitly communicate any risks or blockers and make sure all internal and external stakeholder are aware of them.☢️
• We strive for effective communication general queries are addressed on the same day unless a person is specifically addressed in this case it should be under an hour.📢🗣️
• We log any decisions in teams channel.📔
• We always celebrate our wins by giving specific feedback around the actions behaviors and always celebrate project completion with a team dinner. 🍽️🍺
• We believe in the culture of continuous improvement. We own our mistakes and never sweep anything under the rug, every shortcoming is discussed in retrospective with the team.🧑‍⚖️

Ownership

We always take ownership of our failures and learn from them, every mistake is acceptable as long as its communicated early on and never repeated.

Engineering

• We make conscious engineering decisions to maximize business outcomes.
• There are subset of people who can take design decisions but every engineer in the team is expected to pick any item in the backlog. (unless explicitly stated in kickoff).
• Readability, correctness and resilience are prioritized over performance unless explicitly stated.
• We follow the git flow branch naming convention for branches and identify the task number e.g. feature/123-add-working-agreement
• Commit history is consistent and commit messages are informative (what, why).
• Main branch is always shippable.
• Application faults and errors are logged in production.
• Team is clear about deployment logistics before starting the project.

3rd-party integrations

Teams tasked with integrating a new third-parties into their ongoing projects are required to conduct thorough research and delve into the detailed exploration of the entity’s APIs before initiating the integration process.

• The team submits feedback on business and technical blockers that prevent project success.
• Prevent “Foot-Guns“ if a person makes a mistake, don’t ask: “how could somebody possibly do that?”, do ask: “how can we prevent this from happening in the future?”

Measurements

• Team Velocity

• Number of Bugs

• Iocane Doses