9. Collaboration
How we Collaborate minimizes friction and overhead.
Last updated
Was this helpful?
How we Collaborate minimizes friction and overhead.
Last updated
Was this helpful?
We take end-to-end ownership for team outcomes.
We actively seek information and speak up if we lack clarity.
We don’t hide problems and we value people who bring them to the spotlight.
We ask for help when we need it. We don’t wait for help to come on its own.
We help each other proactively, regardless of team, function or seniority.
We talk to each other and actively engage non-engineers to seek understanding of how and what they work on.
We communicate professionally.
We strive to be .
We avoid interrupting and interjecting.
Departments trust and challenge each other.
We trust first, and give teammates the benefit of the doubt.
We proactively present qualitative and quantitative work results to raise awareness and align on expectations.
We create psychological safety to benefit from each other the most. Shutting people down is not a solution to inefficient meetings.
We need members of each affected chapter present to quickly make informed decisions.
We talk about requirements, scope and proposed solutions throughout the workstream to avoid over-engineering.
Rejecting a pull request with remarks is polite and helps contributors to engage and get better. Accepting pull requests without remarks shows a lack of respect.
We do pair programming with engineers of the same and different chapters. Sharing knowledge makes us smarter. Discussing problems and code in a structured way makes us better engineers.
New key information is discussed, aligned and contextualized in a vertical’s leadership before being shared with the team.
We provide context in communication to minimize back-and-forth.
Our meetings have clear goals and deliverables.
We’re precise (e.g., if a slack message contains multiple questions, we answer them all).
We record decisions and action items.
We make communication channels between departments structured, transparent & cognitive strain-free.
Product owner, designers, agile coach and engineers form a squad.
Every squad has a …
… definition of ready (DoR) for User Stories.
… definition of done (DoD) for User Stories.
All work on the product happens in tickets.
All tickets go through the backlog prioritization and are visible on a board (<30min exceptions are fine).
We use Themes, Epics, Bugs, User Stories and Tasks.
All tickets are limited in scope.
Spikes have clear acceptance criteria.
Feature- and bug-related planning and documentation resides in tickets. All other documents are referenced in the ticket.
There’s no such thing as a non-product, technical story or task.
The business value of all stories is assessed and can be compared.
Each story is refined until the squad align on its meaning, value and scope.