Core Platform Team/PET Work Processes/PET Work Process

Purpose

The Platform Engineering Team(PET) and its sub teams are working to adopt processes that are optimized to improve the consistency and sustainability of our work load, predictability of our delivery, facilitate integration and collaboration with teams across the org, and to create space and support for our Engineers to focus on their work with the least possible administrative overhead.

Our processes should be clear, concise and straightforward for others to plug into, whether they are joining as new members or working collaboratively with us.

PET's work is developed from the PET Roadmap through Initiative Planning to PET Initiatives and Epics/Task on the #core-platform-team board.

Sprint Structure

The PET is trying to use a time boxed sprint structure to identify and complete work that is driven by the requirements of its core projects. The current time bounding is 2 weeks.

Product Teams

Each Product Manager has an associated team - composed of PET members selected based on the requirements of a given Initiative - and work board.

Product 1
Product 2

Pre-sprint

Prior to the beginning of a sprint a subteams Tech Lead, Product Manager and Engineering Manager meet to identify, define and select the individual tasks that will comprise the sprint. The selected tasks should be

Chosen so that they fit into the space provided by the sprint in terms of complexity.
Prioritised clearly
Estimated in terms of difficulty

Kick-off

During this meeting the tasks which will comprise the next sprint are presented to the team for evaluation and discussion. The team can discuss the priorities and estimations of tasks and where necessary the scope of the sprint can be adjusted.

Check-in

The Check-in meeting is held in the regular teams meeting slot the week immediately following the Kick-off meeting. It is the mid point of the sprint where

Sync on progress in terms of the sprint goals
The team discusses any urgent technical issues, resources, blockers or tensions
Communicate any changes to scope that needs to be made

Based on the Check-in meeting, the Product Manager, Program Manager, Engineering Manager and Tech Lead can reprioritise or (re)(de)scope tasks.

Retro

The goal of our processes is that they be adaptable over team to reflect the evolving nature of our teams, our projects and the needs of the both. The process should adapt and team members should have both agency and ownership.

The focus of a retro is not limited to process or the mechanics of how we work, it should equally allow space to discuss work, tools, services, approaches, design and architectural areas where we can improve or build on work we are already doing.

At the end of a sprint we perform a 30 minute facilitated retrospective meeting where all participants in a sprint collaboratively identify what worked well, what needs improvement and what was learned during the sprint. Depending on the number of items raised they are prioritised and discussed.

The output of the meeting is a set of actions to implement in future sprints. These actions can be improvements/changes to the process or highlight behaviours that should continue and be further supported.

The agenda for a retro is as follows:

Generate Liked (2 mins)
Generate Lacked (2 mins)
Generate Learned (2 mins)
Vote on priorities for discussion (4 mins)
Generate Actions/Improvements/Continue discussion (20 mins)