June 21, 2021


News for Agilists

Let’s Stop Creating Silos with Multiple Product Backlogs. There’s Only One! | by David Pereira | Serious Scrum | Oct, 2020

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.

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.

  • 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.

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.

  • 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.
Photo by Edward Howell on Unsplash
  • 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.
  • 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.

Source link