Working in the Authorisation team (aka the A-team), part of the programme building a large-scale government platform, we’re responsible for providing and supporting the means for users to log into the system.

We are one of the platform’s cornerstones and our services are used by pretty much all other teams.

The platform runs on a microservice oriented architecture, and our team is responsible for (at the time of writing) 15 microservices and a few libraries. We’re also a relatively big team within the project with 10 developers, 2 BAs, 2 QAs and 1 Scrum master.

We normally have multiple parallel streams of work, that could be slightly related or not at all. Complexity and communication overhead started to become an issue, but we were concerned that splitting the team might not yield the best results.

We have been trialling a different approach to manage our workload, we call it…

Epic Anchors

Anchors are involved as early as possible on a new epic of work, alongside BA’s and Architects, e.g. participating in initial scoping meetings, with external stakeholders. An epic is anchored by a pair of members of the team, normally developers but can also be a combination of Dev/BA/QA. The key requirement is that the epic’s technical and domain expertise is met by the pair, and they don’t anchor multiple epics at a time.

One of the Anchors normally has a deep domain and technical knowledge of the services being worked on, whereas the other can be less experienced in that area, and so learns by co-anchoring that epic.

They help BAs create stories and spec them out further with QAs in preparation for planning meetings. They also focus on finding unknowns and spike accordingly to obtain answers before the stories are presented to the rest of the team.

They carry out development alongside the rest of the team on that epic, potentially rotating out to pair on other epics. At least one of the Anchors always remains working on the epic whilst it is in active development though. The responsibility of work still relies with the whole team, from Devs to BAs, QAs and Scrum master, and the Anchor role is not confined to a few team members but rotated from epic to epic.

To sum up, the Anchors’ main role is to ensure an epic is delivered all the way into production, with appropriate auditing, monitoring, alerts and dashboards, and that it satisfies the business needs. They are pro-active in resolving blockers and unknowns and ensuring the epic is not being held up. It’s a different role from the traditional team lead as it’s more focused on the delivery of units of work rather than technology, architecture or team management.

How has this worked so far?

So far this has helped us deliver multiple streams of work and help to keep the rotation of team members between different epics fluid according to the load and demand, which would have been much harder if we split the team.

Disclosure: I borrowed the ‘Anchor’ term from Pivotal Labs, a software consultancy I previously worked at.

Written by Gonçalo Silva & Lyndsay Prewer