Italian food vs. Backlog Refinement: a hidden tactic for Scrum Multi-Teams
How we shifted our teams culture from ‘enemies’ to ‘partners’ inspired by Scrum@Scale (S@S).
Spoiler Alert: This secret ingredient of the hidden tactic is the buffet
This is the story of a small organization undergoing agile transformation. In particular this story highlights: backlog refinement and distributing requirements across development teams.
The story comes in 4 parts:
- How we used to distribute work —PM assigning task to PO
- The hardships we faced — Enter the Storm
- What helped us improve — Enter Scrum@Scale
- The hidden tactic — Enter S@S Case Study
How we used to distribute work to Scrum Teams
Our top management team handled work distribution. They distributed initiatives to Product Owners to work on with their Scrum teams.
Distributing initiatives was assigning initiatives to Product Owners on a quarterly basis. The management briefed each Product Owner about the topic they would handle next.
Following that, Product Owners start gathering requirements and derive ‘epics’. They do that in collaboration with relevant stakeholders and the top management team.
The Product Owner met the development teams for ‘Backlog Refinement’ once a week. The Product Owner explained the epics to the development team. Together they broke down the epics into smaller user stories.
Product Owners worked on different topics and so did not share knowledge with each other. Development teams the same thing, except when:
- A team faced blocker due to another team
- A team discovered dependencies on other teams work
This staying-in-the-dark culture created a toxic cross-team environment:
Other teams work is not our work. We don’t care about what happens to it.
The hardships we faced — Enter the Storm
The above process — for a year’s time served us well — or at least that’s what we first thought.
We hit our first road block after one year. We had two separate teams. The two teams worked on separate areas of the same product. No team did knowledge sharing with the other, and that created a bottleneck in the process:
Each team can only work on their area of the product. So, the management could not move one topic from one team to another.
The management refused such restriction. They decided to break the current teams structure. And they created three different teams as a result:
- A UX team focused team to create simpler experience.
- An Architecture focused team to handle core parts of the software
- A Tactical team to handle a wide range of small suggestions.
These three teams had members with mixed knowledge of the product. So that solved our first road block, but still, our priorities changed like the waves of the sea. The team structure fought one wave at a time until one day, the storm came.
The Storm
The center of the storm was a new product. The top management required to build the new product within a 6 months go-to-market plan. The 6 months plan was actually a contractual commitment. so, to safely meet that commitment, the management wanted full teams load to work on the new product.
Even so, the market needs have changed with COVID-19. To address the change, more work needed to be done besides the new product. So the solution was to double the number of teams.
The Storm: a new product that required near-full teams capacity.
The lesson: always be ready to respond to major shifts in priority.
The logic: producing high business value drives success.
What helped us improve — Enter Scrum@Scale
The new product required a velocity near to 80% of our capacity. The management decided to double the number of the teams. The cross team coordination process was fragile. Thus, a scaling framework was needed.
So, for over a month we researched and studied our options to scale Scrum. And our research landed on Scrum@Scale. What we liked about Scrum@Scale (S@S) was:
- The Author being a co-author of The Scrum Guide — Jeff Sutherland
- The concept of a minimum viable bureaucracy (MVB).
- Max decision latency of 24 hours (super helpful to solve blockers).
- The MetaScrum and getting all Product Owners in one team.
We survived the storm with a lot of damage to the work culture. The root cause of the damage was a tight deadline. And our fragile cross-team coordination process failed to hold the teams together.
The hidden tactic — Enter S@S Case Study
Adopting Scrum@Scale was an effective counter measure in itself. The teams worked more effectively on topics that required cross teams coordination.
ِThe next step we are about to take is “Buffet Planning”. We took it from this case-study published Scrum@Scale website.
The normally exciting part is: Italians talking about food.
The exceptionally exciting part is: using that analogy to refine & plan stories.
End note:
The simplicity about “Buffet Planning’ made me feel happy inside. And to summarize the story, I leave you with one thought:
Backlog refinement in a buffet-like fashion — for every dish, tell a story
Thank you very much for reading. If you feel like sharing feedback, write me a reply or send me a message on LinkedIn or Twitter.
Do you want to write for Serious Scrum or seriously discuss Scrum?
