It took us some time to figure out a good way of handling architectural topics within our Scrum environment. In this post I’d like to share how we deal with technical debt vs. feature development, how teams contribute to the architecture and our way of syncing on architectural topics across the teams.
The current setup (brief description)
Each of the development teams works with a dedicated team architect – (s)he’s a real developing team member. We conduct a weekly Scrum of Architects that lasts 1 hour to discuss architectural topics raised by the teams, architectural topics in general and to decide on so called Tech stories.
Some more details:
The role team architect
- guides and supports the team creating software designs and revising existing ones by suggesting possible refactoring or redesign necessities.
- enables decision making on architectural questions in the team and across teams
- by sketching a design in the sprint planning and/or as sprint preparation + during the sprint
- being involved in all architectural discussions
- plays an active role in code reviews
- fosters sync on architectural topics across teams
- creates and fosters approval for tech stories raised by the team
- supports the product owner in pre analysis of stories, defining business values and priorities for tech stories
- still helps developing important software parts (to stay in touch with the code and to see architectural areas)
What about tech stories?
In addition we learned that the a product owner does not have the deep technical understanding to create these stories and make priority decisions on it.
Tech story lifecycle
- The team architect or the chief architect creates a tech story and adds it to the tech story backlog (an own backlog for all tech stories – see it as an incubator before a tech story is allowed to go into the product backlog for a team)
- The tech story is checked by an approval team – if necessary changed and finally approved or rejected (based on discussion).
- It’s decided what team could implement the tech story (mostly tech stories come from a team – this way the assigning is obvious)
- An approved story is added to the teams product backlog.
- The product owner and team architect decide on the priority.
- The tech story is estimated in the next backlog grooming session and the priority gets adjusted with the new information.
- A tech stories goes in a sprint when it’s the next story to pick up from the product backlog. The team architect helps the team to understand the background and moderates this part in sprint planning I+II
- The implementation gets reviewed by the team architect and for bigger stories in the Scrum of Architects.
The Scrum of Architects meeting
- to discuss architecture topics raised by the teams or raised from the chief architect or tech lead
- it ensures a tech sync across the teams
- common tech impediments get visible
- it hinders having more than one team working on the same topic without knowing it
- have a tech story backlog grooming and approve/reject/request for change on not yet considered tech stories (the story creator explains the background in details – it’s like selling the story)
Everyone can follow and contribute
- The team has a strong voice through the team architect
- Architectural information is accessible
- via the tech stories and its store – the tech story backlog
- a tech blog
- public meeting minutes
- an active information sharing by the team architect
- The product owner can maintain the product backlog including tech stories with the help of the teams architect.