Inspired by, but is not the Spotify model. It’s the mx51 model. This section is intended to highlight how we structure teams for delivery rather than how we structure roles for careers and line management. They are different.
A group of people using a group of technologies in a common domain such as backend, frontend, Android or POS integrations.
A Chapter Lead (CL) makes decisions and choices across squads for one technology stack or capability. This role is normally performed by a senior or above for instance across BE or FE or Android. The CL will organise regular sessions with the chapter members to discuss amongst many things; new technologies, patterns, etc.
A CL may assign ownership of systems, components, modules, designs and products from a technical perspective to people within the Chapter.
This is not a people management role.
BAU work should still be managed and allocated to engineers who will be allocated to a squad.
Chapter-Lead Responsibilities ¶
- Chapter BAU Work
- Manage the BAU work for the chapter. Ensure the backlog of work for the Chapter is clearly defined, prioritised and can be shared easily amongst the team. Allocate work to the team according to the BAU roster.
- Chapter Communications
- Ensure that members of the chapters come together periodically to discuss current issues facing the chapter
- Chapter Roadmap
- Apart from the BAU work that should be carried out, ensure that any bigger pieces of work are identified and determined whether they are broken down into work items that can be managed within the BAU workflow. For larger projects, engage the Technology leadership to drive projects outside of the BAU workflow by creating proposals and getting buy-in from the business.
A group of people building and running something that creates user value. Can be cross functional in terms of engineering skills and product, UX and QA. An example being the “MXA Core” squad.
Squad People ¶
Dedicated People in the Squad ¶
- Building, dedicated to one squad to ensure delivery to estimates and plans
- These can be from any technology discipline
- Engineers can move squads but can’t concurrently work in more than one
Shared People in the Squad ¶
These people must attend the squad ceremonies such as planning, grooming and stand-ups if they have been assigned to a squad.
- Product Manager
- Representing customers (across multiple squads)
- Testing (across multiple squads)
- UX Research and UX Designing (across multiple squads)
Shared Services ¶
These people aren’t dedicated to a squad.
- Data & ML
- Cyber Security
- Product Architecture
Squad Roles ¶
These are not Career Levels but roles people take on when working in squads. These are not intended to create extra work but clearly identify where the responsibility and accountability lies which aid decision making.
Squad Quorum Roles ¶
Minimum people to make decisions on:
Other team members can be involved but aren’t required. The intention of the quorum is to ensure responsibilities are designated clearly.
- Squad Product Lead
- Normally a Product Manager who guide the team on the customer needs
- Squad Technical Lead
- Normally a senior dev, team lead, staff engineer or principal engineer who aligns the technical build across all tech disciplines. Consults with principal engineers to ensure alignment across all technology is consistent.
- Squad QA Lead
- Normally a senior QA who makes sure the solution meets the customer needs
- Squad UX Lead
- Normally a senior UX who makes sure the customer will be able to use the solution
Squad Role Tenure ¶
The roles in the squad will be reviewed periodically (currently, every 2 Increments). This intentional review, is to normalise the change of people in the role. By making it periodical, this allows opportunities for squad members to step up and experience the lead positions without committing to a long term role. This has benefits for the team and individual. Individuals get the experience of coordinating people, deepen their product knowledge, get experience in prioritising work. The team gains with a diversification of leadership (de-risking overall delivery), their squad members develop a broader understanding of the product and the business drivers.
Squad Technical Lead ¶
- Work ahead of the sprint to ensure stories contain enough technical detail for the squad to discuss and size
- Participate in prioritisation and planning discussions with product manager and designer
- Prioritise technical items for inclusion into future sprints (e.g. bugs, tech debt, security, etc) (Note – Chapter wide BAU items are not to be prioritised within the squad)
- Coordinate with Technical squad members in the technical design of features.
- Facilitate the design outcome, not necessarily do the design itself
- Involve the Product Architecture Chapter as required.
- Coordinate technical investigations into issues.
- Ensure estimates are provided for technical tasks
- Where necessary, act as the technical spokesperson to communicate any technical concepts, issues that the team is facing.
- Coordinate with the wider team around release management.
As with other squad roles, the squad technical lead role will be reviewed periodically (currently every 2 Increments).
Home Squads ¶
Typical Home Squad tasks might include: patching of software, applying fixes after a pen test, increasing code coverage, fixing technical debt, aligning implementation to new patterns, updating or upgrading a SaaS tool, security fixes for a SaaS tool, load testing, implementing new tooling, etc.
The Product Manager will be responsible for the user facing product and the Tech Lead for technical tasks such as fixing tech debt. The process for agreeing when this work is completed is by negotiation between the Squad Quorum. Some BAU work will have deadlines based on risk and compliance needs such as security fixes that are required to be completed by a certain date.
User stories, epics, tasks etc are managed in JIRA
Roadmaps are maintained by:
- Product teams for product features
- Technology teams for technology initiatives
- Delivery team that focus on the rollout of products to our customers
We work in 2 week sprints. We have 3 of these in an increment. Major milestones are delivered at the end of an increment but releases happen daily. Pilots are conducted before moving into BAU.
Sprint Planning ¶
Whole squad meets each sprint to discuss, agree and align on what will be achieved in the next sprint. Stories and tasks for the sprint must be refined and “ready” prior to this ceremony.
Sprint Retrospective ¶
Whole squad meets at the end of each sprint to reflect on the sprint, agree areas to improve how the squad works together and assign actions for continuous improvement.
Backlog Refinement ¶
Squad quorum meets to ensure the backlog is prioritised and contains sufficient detail to be “ready” for a future sprint. Decisions on detailed architecture, user experience and assumptions are made.
Whole squad meets on a regular basis to raise questions, concerns and blockers for awareness. Actions and in-depth discussions to happen outside of stand-ups.