May 18, 2015
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…
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.
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
All business models have their pros and cons. But, when you consider the type of problems we help our clients to solve at Equal Experts, it’s worth thinking about the level of experience and the best consultancy approach to solve them.
If you’d like to find out more about working with us – get in touch. We’d love to hear from you.