Why is it taking so long? How did no one catch that bug? Why didn’t anyone else know about it? And what does this actually mean for us right now?
You’ve probably heard one of these questions in your project at some point and wondered whether your team’s workflow could be a bit more optimized.
Feel free to use this as inspiration — take what resonates, bring it to your team, and vote on it democratically. It’s important that everyone on the team truly shares the same understanding. Team agreements should therefore always be formulated explicitly.
In this article I cover team agreements that are methodology-agnostic. It doesn’t matter whether your team uses Scrum, SAFe, or simply works in an agile fashion.
The first three rules should be familiar to many:
1) Stop Starting, Start Finishing
This means only picking up new stories (work packages) once the ones already in progress have been completed. This applies regardless of whether they’re your own stories or a colleague’s. Offering support is always the priority.
2) Four-Eyes Principle
Every change should be seen by at least four eyes — pair programming or code review.
3) Focus on Value
Every story should be self-contained and encompass the relevant sub-topics.
When refining a story — or at the latest during the kickoff — the business value should be questioned and the story framed from a business value perspective. This does not apply to classic usage scenarios that are documented as user stories from a user perspective.
4) Zero Bug Policy
Bugs that arise go straight to the top of the backlog and are covered by tests. Production bugs are fixed immediately; everything else is addressed no later than the following sprint. To maintain team transparency, a potential lesson learned should be communicated.
5) Kick-off After Refinement
A kickoff aims to establish a forward-thinking working mode within the team. It prevents misunderstandings, reduces redundancies, and supports the ongoing flow of topics.
During refinement, topics are discussed at a high level and often voted on directly by the team. To keep shared meeting sessions focused and productive, topics should not be discussed in too much detail at this stage.
The team member who picks up a topic should first dive into it independently, then discuss it with other colleagues. The emphasis is on bringing together different perspectives (Business, Design, Development, QA). Details and technical specifics can be clarified in that setting.
6) Handover Before Done
Both the kickoff and the handover aim to bring together different perspectives. The “Three Amigos” principle applies: Business, Design, Development, and QA should all be present. The Product Owner can participate but is not required to take on a formal role.
During the handover, the team checks whether all topics have truly been addressed. Were all ACs (acceptance criteria) implemented? What is the status of DoDs (Definition of Done) and DoRs (Definition of Ready)?
Pro tip: Use a checklist in the ticket description as a template.
- ✅ fulfilled — works
- ❌ not fulfilled — doesn’t work
- 💀 not applicable
7) Agile Mindset
Those who don’t move with the times will be left behind.
To establish agile ways of working, each individual’s personal mindset is essential. It is a fundamental prerequisite for every team member. The following points deserve particular attention:
Feedback loops; active participation; proactivity; no multitasking; adaptability; moderation rotates through the team; camera on; continuous improvement; customer focus;
If individual team members lack an agile mindset, it can pose a significant project risk.
Watch out especially for colleagues who make statements like:
Never change a running system.
or
We’ve always done it this way.
These attitudes can be dangerous and are not a sign of high innovation. Before you know it, the product gets caught up by more innovative solutions and ultimately discontinued. An even worse scenario: team cohesion suffers and colleagues leave the project or resign altogether.
8) Rebase Instead of Merge
We prefer rebasing our changes over merging. This keeps the Git history clean and makes it easier to revert changes.
9) Fixup & Squashing
All changes should be grouped into individual commits to keep them traceable. Using squashing, commits can then be meaningfully consolidated.
Sometimes you want to extend an existing local commit with additional changes without touching newer commits.
For this, fixup commits can be used (git commit --fixup <COMMIT HASH>).
10) ONE GOAL
10.1) Sprint Goal Checks
A shared understanding of the vision and common goal is crucial for an effective team and the success of the project. In every iteration of product development, a measurable goal (in Scrum: the Sprint Goal) should be defined.
Pro tip: This goal should be reviewed daily as part of a Sprint Goal Check. The check helps the team build a shared understanding of whether the goal is achievable. For example, you could vote using Fist to Five and discuss further if there are large discrepancies or when needed.
10.2) KPIs
The team should have access to KPIs in order to validate assumptions and further optimize the software. Issues like downtimes can be identified and resolved before the customer even notices. ONE GOAL also means thinking from the customer’s perspective. Empathy is the key to healthy and sustainable software.
New Relic is an excellent tool for visualizing performance KPIs. Matomo, as a privacy-friendly alternative to Google Analytics, can be used for analytics. Matomo also offers the option to run A/B tests within your application.
Pro tip: Review the KPIs together as a team once a week and discuss them.
10.3) Alert Babo
The Alert Babo is a person who checks the alerts in the alert channel, Prisma, New Relic dashboard, Splunk, CloudWatch, etc. on a daily basis and decides whether further action needs to be taken.
It is especially important to identify and capture high-priority bugs and critical issues. Recurring errors or warnings can, after team discussion, be whitelisted if appropriate.
Pro tip: Keep the Alert Babo’s plate clear so they can focus on the alerts. Also rotate the role within the team on a weekly basis.
