Why do we love to complicate things? Why do we want to overcome challenges with new processes? Until we have a real agile mindset, we cannot benefit from an agile framework.
“A clever person solves a problem. A wise person avoids it.”
― Albert Einstein
Doing Scrum with one team might be simple, but once we start scaling with multiple teams, we face new challenges. That’s why we may find a way out by introducing new processes. Bit by bit, we transform our Scrum into a heavy machine, ultimately leading us to inefficiency.
A common misconception is creating multiple backlogs for the same product even though Scrum is pretty clear. One product, one backlog.
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
Scrum is supposed to be simple. That’s why, when we need to scale, we should keep it simple as well. Once we create more processes, we inevitably reduce collaboration. People tend to become less creative and more process-oriented. To thrive, teams need to have an environment that prioritizes collaboration over processes.
If you want to work with multiple backlogs for the same product, you better know what waits for you:
Confusion. Silos. Frustration.
I’ve been in some situations where we had multiple backlogs for a single product. Even in different companies with different variants, the result was the same: Teams got locked into silos that held them from succeeding.
The idea behind splitting the Product Backlogs into different boundaries (tech, discovery, and so on) is that teams can organize the work easier. For example, technical requirements could be managed fully by the Development Team, or the Discovery Team manages discovery backlog. But the consequences of this set-up are:
- Misunderstanding: teams for the same product may work towards different directions. They don’t know what the other teams are working on or planning to do.
- Silos: every team has a specific responsibility. They collaborate less and focus more on their part. The agile mindset disappears.
- Frustration: developers feel like assembly line workers. They execute what the discovery team defines as important, but they are not part of the whole. They are mere executors.
- Confusion: the Product Owner struggles to understand what is going on because she might not have an eye on each backlog. Multiple backlogs put teams in multiple directions. Dependency among teams increases, while efficiency decrease. The Product Owner focuses on the process instead of maximizing the value.
In my opinion, multiple backlogs for the same product should not be an option. If we want to foster collaboration, we have to avoid splitting the Product Backlog into different boundaries.
We should keep an agile mindset. Once we decide to scale Scrum, we should be aware that we also scale the dysfunctions. They should be fixed before scaling. That’s why we should avoid creating new processes; they won’t solve the root cause.
One Product Backlog ensures simplicity.
- Everyone works in the same direction.
- Team members keep the big picture in their minds.
- Collaboration is natural. Silos have no place.
- Dependencies are reduced due to the stronger collaboration between the teams.
- No overhead to manage multiple backlogs.
During my journey, I’ve observed a common pitfall. Many companies start scaling before they master Scrum with a single team. Therefore, they face many problems while adding more teams. Before we think about scaling with Scrum, we should be able to do Scrum properly. That will save us from endless drawbacks.
If we do Scrum, we can scale with Scrum. Real Scrum teams are:
- Cross-functional: the team has all skills needed to build meaningful and delightful products.
- Self-organized: the team defines how they work. Nobody needs to manage them. The team is responsible for themselves.
- Autonomous: the team is empowered to make any decisions as needed. They don’t need to ask for approval.
- Goal-oriented: Sprint by Sprint, the Scrum Team focuses on achieving the Sprint Goal instead of delivering tasks. The Sprint Backlog is not a prison. The team has the space to do whatever they want to achieve the goal.
- Empirical: the team accepts they don’t have all the answers up front. They build and learn. They take feedback seriously. The Scrum team becomes a better version of itself Sprint by Sprint.
It may seem obvious what I’ve just written, yet it’s not reflected in many teams. Many teams think they do Scrum, but they are:
- Incomplete: not all skills are present at the team. For example, the designer is part of another team and has a different set of priorities.
- Features-driven: the goal is to deliver features. At the end of the Sprint, what matters is shipping new features. More is synonymous with better. The Sprint Goal is ignored.
- Overconfident: the team perceives the validating hypothesis as a luxury waste of time. They know exactly what to build. Therefore, the focus is on building instead of an understanding of what to build.