Agile Handshake 🤝: Unlocking shared understanding in Engineering teams

In the dynamic landscape of software engineering, success hinges not only on the quality of code but also on how well a team collaborates. Through my experiences leading various engineering teams, I’ve discovered a powerful practice that goes a long way in ensuring your teams have a shared understanding of intra-team and inter-team processes — it’s what I call the “Agile Handshake.”

This ritual serves as a compass, aligning teams on shared principles, practices, and collaborative ways of working. Let’s delve into the intricacies of the Agile Handshake and how it has proven to be a game-changer.

How does it look like?

Typically it looks like a confluence document specific to a team that defines ways of working of that team from various aspects. When I say team, I mean a fullstack team of different types of engineers, product manager, designer, and engineering manager.

For example, an agile handshake with one of my teams defined ways of working, rituals, and standard practices with regards to:

• Product Backlog
• Sprints
• How we do Story Point Estimates (SPE)?
• Customer Centricity
• Engineering Excellence
• Stakeholder Management

It could also be an inter-team document, defining how two or more teams agree on working with each other, including SLAs, spearation of responsibilities, etc.

What does that mean in detail?

I will now share a breakdown of what kind of rules or practices we defined in each of these sections. Note that I’m using group terminologies like “we” and present continuous tense like “we make”, “we use” intentionally, so as to indicate that we as a group sign off on following these practices.

Remember, these are things that worked for my team. You and your team could define your own ways of working:

1. Define how we as a team manage our product backlog

The foundation of our Agile Handshake lies in how we manage our Product Backlog:

• When we define epics, we break the requirement down to small stories/tasks, each of which have customer impact
• We make Product Backlog Items (PBIs) like epics, stories, tasks, and bugs as granular as possible
• We use stories for user facing items and tasks for more detailed technical work items
• Definition of Ready: We write clear, objective Acceptance Criteria in each PBI
• Definition of Done: When a PBI is moved it done, it is implied that it is deployed to production
• When we see a PBI bloating up with scope, we split it into smaller ones
• For scope creeps found during the sprint, we add the corresponding details to a ticket (new or existing). Missing business logic to be written by Product or Design. Missing technical logic to be written by engineers. Missing / incomplete / outdated designs to be created by design
• PBI Definitions: A story is a user facing deliverable. A task is a technical high level task that may relate to a user story (dependency should be added in Jira where applicable). A subtask is a smaller component of a task or a story.

2. Define how we as a team run our Sprints

• We follow scrum
• We have daily synchronous 15 min stand-ups
• We split ownership of standup in a round robin fashion
• We have weekly refinement meetings where anyone can bring new PBIs or designs to refine
• We have weekly Datadog monitoring to identify errors or unusual activity not caught by our alerting
• We have 2 week sprints and bi-weekly sprint ceremonies
• Review (demos for current sprint) → Reflect (retro for current sprint) → Refine (planning for next sprint)
• Post Review: EM/PM to align on what, if anything, is to be announced to stakeholders
• In a sprint we dedicate: 60% bandwidth for product work, 20% for engineering maturity (bugs, improvements, test coverage) and product maturity (feature requests), and 20% spare capacity for scope creep or escalations (or picking up new items from backlog)
• The estimated cycle time of a PBI from In Progress → Done does not exceed 3 working days. If it does, we break down the PBI further.
• We make monthly milestones for engineering

3. Define how we as a team do Story Point Estimates (SPE)?

• What we estimate: SPEs consider the implied engineering maturity standards: writing unit tests, integration tests, potential review time, manual testing if needed, and time to deploy
• Method 1 (non-abstract): SPE is the number of person days required to complete the task
• Method 2 (abstract): a 3-dimensional view on scope, complexity, and potential uncertainty (we chose Method 2)
• We agree to have ideal SPE size as small as possible (target: less than 3)

4. Define how we as a team inculcate a Customer First Mindset

• We start with the end in mind and do problem solving by thinking of customer impact
• We understand and know who our customers are, and align on impact to them before implementation.
• We keep a proverbial seat at the table for our end customer when defining / refining new features
• We agree to be customer first, company second, team third, and individual last

5. Define what Engineering standards we as a team agree to meet

• We follow Test Driven Development i.e. We agree to implicitly write unit tests and integration tests, event though they are not a part of acceptance critera
• We agree to have 95%+ branch coverage for all newly written code — including BE & FE
• We follow Secure SDLC (SSDLC) — Secure engineering practices are baked into our code
• We never store or transport passwords or keys in cleartext
• We encrypt data at rest and data in transit
• We do NOT commit code with keys (API keys, secrets, etc.). If we do by mistake, we squash those commits
• We do NOT write BE logic in FE
• We avoid magic numbers in code and instead write them in config files if necessary
• We #buildforscale i.e. we design services with the potential for exponentially scaling them in future
• We don’t write service configurations in code, we instead use API gateways
• We deploy code to production in small size and frequently, targeting a deployment frequency of 5 deployments per engineer per sprint
• We keep new PRs less than 400 LoC
• We do ADRs for new services, new major features, and major architectural changes
• When faced with a choice, we choose to do the mature thing over a hacky workaround

6. Define how we as a manage internal stakeholders

• We, as engineers, are as responsible as our EM/PM to keep our stakeholders aligned (on ticket updates, timeline changes, breaking changes, etc.)
• We align internally before stating opinions on behalf of the team (when needed)
  In public forums, we represent our opinions more as a team and less as an individual member

Let’s wrap it up

In conclusion, the Agile Handshake is more than just a document; it’s a living agreement that fosters a culture of shared understanding and continuous improvement within engineering teams. By explicitly defining team principles, practices, and standards, it empowers team members to align on a common vision, streamline workflows, and deliver value more effectively.

Embrace Agile Handshake 🤝 to unlock the full potential of your engineering teams, fostering collaboration, customer centricity, and engineering excellence in every sprint.