Agile Management with Microservices Team
When it comes to microservices design with multiple squads, defining the right agile team structure with effective coordination becomes a considerable challenge.
Maintaining the quality and sustainability of the services requires the engineers to stay focused. Hence, a traditional Agile team with diverse knowledge to tackle feature-based issues is impracticable. However, a user request typically involves several services. This situation becomes a dilemma between Agile practice and engineering best practice.
Our team faced the same problem when the team size grew larger while more services developed. So what did we do? We made two major changes.
Run Nexus
First, we decided to reference Nexus, a Scaled Scrum framework from scrum.org, and we quickly formed a Nexus team to solve the coordination issues we had. At the same time, the squads continued to focus on their respective services.
Same as a standard Agile team, the Nexus team hosts daily standups, review and retrospective meetings, with the focus more on coordination.
One of the major responsibilities of the Nexus team is user story refinement from a high-level perspective. It gives the team representatives a chance to understand and discuss what each team needs to do to satisfy the business need. After that, they go back to their individual squads to further discuss technical detail with the engineers and to explain the rationale behind the stories.
Use a Single Board
To maintain product transparency, we use a single board for multiple squads. But how do we manage our Agile board? Similar to most of the Agile teams, we have epic, user story, and task cards. However, we have another level between user stories and tasks, and we call them team stories. Instead of moving stories to different stages, we move tasks only. Once all the tasks of the story are done, the story would be considered as done.
- Epics — Owned by the Product Owners. The simple description of broader goals
- User stories — Owned by Product Owners. The feature-based end-to-end testable request from users. It absolutely should not contain any technical detail, and it must derive from an epic
- Team stories — Owned by the development team. Usually defined by team representatives. They are high-level action items that need to be done by different squads to fulfil the requirements. And they must be derived from a User Story
- Tasks — Owned by the development team that is defined by engineers. They are actual technical tasks that need to be done to fulfil all requirements of a Team story.
Story size estimation became meaningless as all squads are using the same board. To determine the effort of a story, we count the number of tasks and do our best to make sure each task can be done within a maximum of two days. In this case, we can estimate the effort much more accurately.
The Nexus team and the new way to manage our Agile board helped our coordination work significantly. We actually run Scrum in the beginning, and we switched to Kanban for an even quicker response to the users. Both frameworks work very well. I hope our management way could give you some insights if you have the same challenge.
