It is important to look at ways to overcome the challenge of successfully using Scrum on a large, multi-team project as Agile or scrum is not for all projects but for Complex or complicated projects.
1.1 Scaling the Product Owner role
Large Scrum Project consists of many small teams working together. Of course, one Product Owner cannot be the Product Owner for all the teams. Also rarely will a single Product Owner have all the knowledge about all business functions to be implemented or changed.
Generally, the following hierarchy is followed for large enterprise implementations.
Most people new to Scrum ask this question “But Product Owner is supposed to be ONE single person and not a committee, How can you have a hierarchy? Doesn’t it mean that you have a Product Owner committee?”
The answer to the question is that there is NO Product owner Committee that I am talking about. Each Product Owner is responsible for “The Product that he is responsible for”. It’s not a group of people responsible for the Product.
In the above example, there is a Product Owner for Accounts. The Product Owners who handle Savings Accounts vs Current Accounts (Business Accounts) work with the Accounts Product Owner. That means the “Accounts PO” is accountable for the entire product “Accounts”. The “Savings PO” is accountable for the “Savings Account” as a whole functionality and “Current Account PO” is accountable for “Current Account” as a whole functionality.
The Chief Product Owner is a role who is in charge of guiding the other Product Owners. This individual ensures that the needs and requirements are consistently communicated to the various teams and that the project-wide progress is optimized. This will also include facilitating collaborative discussion, decision making as well as having a final say if no consensus can be reached.
1.2 Scaling Product Backlog
Most large project teams opt to use one of the commercial agile tools that provide support for working with a large product backlog. There are two guidelines worth pointing out that remain valid regardless of which backlog management tool is selected
· If there is one product there should be only one product backlog
· The product backlog should be kept to a reasonable size
1.2.1 One Product, One Product Backlog
Having a single product backlog allows the chief product owner to see the relationship between the top-priority features across the product. Logistical problems can arise however when multiple teams and multiple product owners work with a single product backlog. All features should be prioritized relative to the other features. This can be extremely difficult to do on a project with numerous product owners, multiple product line owners, and chief product owner. Rather than allowing each product owner to maintain his or her own private product backlog, a better solution is to have a single product backlog but to provide views into it for each product owner.
1.2.2 Keep the Product Backlog to a Reasonable size
We need to balance our desire for a single product backlog with the competing desire that the product backlog did not become unmanageable.
There are two ways of keeping the number of backlog items manageable.
· Make use of Epics: By writing some large stories (epics) on the product backlog, even the product backlog or an immense project can be made to fit into no more than approximately 150 product backlog items.
· Provide views into the product backlog (Themes): Theme is a way of grouping similar product backlog items into groups. This will allow the chief product owner to view the product backlog as a set of views (themes). The individual teams and the product owners, however, can see individual user stories written at the level of detail they need to turn each into new capabilities in the product.
1.3 Scrum of Scrums
The Scrum of Scrums (meeting) is a technique to scale Scrum up to large development groups (over a dozen people), which allows clusters of teams to discuss their work, focusing especially on areas of overlap and integration. Each daily scrum within a sub-team ends by designating one member as an “ambassador” to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums. Depending on the context, ambassadors may be technical contributors or each team’s Scrum Master.
The agenda will be like a Daily Scrum, with the following four questions:
· What has your team done since we last met?
· What will your team do before we meet again?
· Is anything slowing your team down or getting in their way?
· Are you about to put something in another team’s way?
Resolution of impediments is expected to focus on the challenges of coordination between the teams and may entail agreeing to interfaces between teams, negotiating responsibility boundaries, etc. The Scrum of Scrums will track these working items via a backlog of its own, where each item contributes to improving between-team coordination.
1.4 SAFE Framework
Scaled Agile Framework (or SAFe) is an agile software development framework consisting of a knowledge-base of integrated patterns intended for enterprise-scale Lean-Agile development. Its proponents consider SAFe to be scalable and modular, allowing an organization to apply it in a way that suits its needs.
SAFe is based on a number of immutable, underlying lean and agile principles. These are the fundamental tenets and economic underpinnings that drive the roles and practices that make SAFe effective. The nine SAFe principles are:
· Take an economic view
· Apply systems thinking
· Assume variability; preserve options
· Build incrementally with fast, integrated learning cycles
· Base milestones on an objective evaluation of working systems
· Visualize and limit work-in-progress, reduce batch sizes, and manage queue lengths
· Apply cadence (timing), synchronize with cross-domain planning
· Unlock the intrinsic motivation of knowledge workers
· Decentralize decision-making