Sacling with Scrum @Scale: Factors to Consider and Good approachs to Team aLIGNMENT.

Sharing my experience in scaling agile teams with Scrum @Scale. This is the last part of the series in scaling Agile teams with Scrum @Scale. To read the first blog post, click here.

Factors to consider while Scaling Agile Teams

From my experience and other colleagues of experts in agile transformation, especially in scaling, large organization believes in three things; Silver bullet promises of categorizing agile frameworks as best practices; Sending employees to expensive training and certifications, and Consultation offering from big consulting firm. These are all good for transformation. The major challenge with this approach is that they miss the major points and values of scaling which are Managing dependencies, alignment, synchronization, creating common understanding, achieving business agility of satisfying customers’ needs faster, and getting customer feedback.

Best approaches for an effective alignment between multiple teams using Scrum of Scrums?

Organization should have a defined goal, tracked with Objectives and key results (OKRs) of what they want to achieve with scaling. These could be, proactively responding to the changing environment, manage fast flow of value, build customer centric organization by aiming for faster feedback and continuous learning, coordination/alignment between multiple products, and/or achieving business agility by having an adaptive organizational design.

Create the working agreement for SoS. This should involve all the Scrum team members. The workshops should be facilitated by an agile coach/senior leadership who understand the importance of Working agreement as must have for group. I have experienced that when everyone/most agrees on how they want to organize themselves, it brings the autonomy of choice and ingredients of motivation for the team members.

Decentralize decision making. Set boundaries to decision that should be made from the top and the decision that requires the collaboration of the knowledge workers.  Let the management voice echo the problem and the knowledge workers voice echo the solution.

Explicit definition of responsibilities and accountabilities between the Product owner cycle and Scrum master cycle: Who takes care of the product feedback and who takes care of the release feedback? Which part should have a shared responsibility? This responsibility and accountability should be explicitly defined before it hurts the velocity and quality of product delivery.

Having leadership support and involvement in the scaling process. Communicating the vision and strategy regularly, by applying the three Cs (communication, communication, communication) of change management is very important in scaling transformation.

Management focus on the output with unnecessary metrics rather than on the value, outcomes and key learning is another pitfall I have experienced in scaling. When the focus is not on the value, outcomes and key learning, there will be less/no room for innovation. These are also indicators that the environment for empiricism is not encouraged. Typical scenario of organization with mercenaries instead of missionaries.

There is a misconception that agile is a solution to everything, which I consider false. There are issues/challenges/problems that cannot be solved by scaling agile team, these may include technology constraint, lack of vision and strategy, Team immaturity in agile/Scrum, team dysfunctions, unsuitable organizational design, and unsupportive leadership.

Executive MetaScrum should consist of senior leadership (Portfolio, Finance, PM, Marketing, Sales, Compliance) who is ready to walk the walk towards achieving business agility with lean budgeting.

There is no end journey towards agile scaling. It never ends, it is all about continuous learning and continuous improvement. The common mistake I have experienced often is having a timeline for agile transformation. No, there is no timeline, the major benefit is to be agile enough in responding to change that affects the business and that of the customers.

One single source of truth by having a one product backlog. A good chief product owner is very critical in the success of SoS. I have seen a Scrum of scrums that have multiple product boards, each team having a full responsibility of the board without a sync board for the Scrum of Scrums. While these could have an advantage, the impact of the silos on the product/solution will hurt the velocity of the integration and quality in general. Another risk that I have encountered firsthand is the duplication of jobs by more than one team, because of lack of transparency and synchronization.

Must have “Golden standard” with minimum definition of done (DoD). This should set the standard and best practices for quality of your product across the teams in Scrum of Scrums (SoS) or Scrum of Scrums of Scrum (SoSoS). Knowing this is the bare minimum, which no exception should be accepted in the integration points is the root of quality products/solutions.

This is the last part of the series in scaling Agile teams with Scrum @Scale. To read the first blog post, click here.