Delivery

Inspired by, but is not the Spotify model. It’s the mx51 model.

Our approach uses “Tribe Model Management” and uses Agile principles as a framework that is malleable and allows us to quickly adapt in rapidly changing environments. It provides a common language and a guide for our people to follow.

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. It also highlights our ways of working.

Tribe Model Management ¶

Squads ¶

A squad is 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 “in-store merchant experience app” squad.

Tribes ¶

A tribe is a collection of squads grouped by a common business area of focus, e.g. in-store.

Chapters ¶

A chapter is a group of people who works across different squads using a group of technologies and/or practices in a common domain such as backend Go, frontend JS, QA, security or Android.

Explained ¶

Squads ¶

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 “merchant self-serve” squad.

Squad People ¶

Dedicated People in the Squad ¶

• Engineer
  • Building, dedicated to one squad to ensure delivery to estimates and plans
  • They can be from any technology discipline
• Product Manager
  • Representing customers and their needs
  • Leading requirements gathering
• QA
  • Testing
• UX
  • UX Research and UX/UI Designing

These people must attend the squad ceremonies such as planning, grooming and stand-ups if they have been assigned to a squad.

Shared Services ¶

These teams are core to our business, but are not allocated individually to squads. They are consulted throughout our build process by the squads, and will work across all squads as needed. They maintain their own team cadence, and coordinate with the Delivery team when they’re needed by the Squads.

• Data & ML
• Cyber Security
• Infrastructure
• Delivery
• Architecture

Squad Roles & Responsibilities ¶

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:

• Roadmaps
• Solutions
• Designs
• Backlogs
• Priorities
• Releases

are:

• Squad Product Lead
  • Normally a Product Manager who guides 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. Leads consultation outside the squad to ensure technical change is understood across Engineering.
• 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

Other team members can be involved but aren’t required. The intention of the quorum is to ensure responsibilities are designated clearly.

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.

Tribes ¶

Tribes Roles & Responsibilities ¶

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.

Minimum people to make decisions on:

• Roadmaps
• Priorities

The quorum is made of:

• Tribe Product Lead
  • Normally a Group Product Manager who guide the team on the customer needs
• Tribe Technical Lead
  • Normally an Engineering Manager

Chapters ¶

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.

Delivery Framework ¶

Project Kickoff ¶

Kickoff the project for further refinement of scope and deliverables. Kickoff technical discussions as required.

Story Mapping and Planning ¶

Capturing all the user stories and tech stories as required. The team identifies unknowns, captures them as spikes and prioritises them to unblock the future development.

Backlogs ¶

Epics, user stories, tasks etc are managed in JIRA. Jira is the source of truth. A user story is ready for development work only when the “Definition of Ready” criteria is met.

Planning ¶

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

Releases ¶

We work in 2 week sprints. Most squads will have a release per sprint, some one per increment. We follow a specific release process led by the Delivery manager, QA lead and Product to ensure consistency and efficiency. Major milestones are delivered at the end of an increment but releases happen daily. Pilots are conducted before moving into BAU.

Ceremonies ¶

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. The squad sizes the effort of each story/task. Backlogs should be ready for a minimum of 2 future sprints.

Stand-Ups ¶

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.