5 Practices To Start Scaling Agile

When considering scaling Agile, it is important to start small. Some of the various scaled Agile frameworks available can look incredibly complex, while others can look simplistic and incomplete at first glance. Relax. Don’t over-complicate it. Start small with these proven best practices—and then fill in the rest as your Agile journey continues!

Situation

How do you know when to apply Agile at scale? Before we talk about scaling, let’s determine if you truly need to scale. Common situations causing a need for scaling include:

  • More and more large initiatives that require multiple teams
  • Limited collaboration between teams working on similar or dependent efforts
  • Late-breaking dependencies that impact the delivery schedule
  • Teams focused primarily on their deliverables, often at the expense of the larger program objective
  • The pursuit of full enterprise agility beyond just team-level agility
  • Burning platform—current way of doing business is inadequate to survive

Many enterprises have experienced success with Agile at the team level. Their teams are working iteratively and incrementally, delivering some form of business value every 2 weeks. But then they realize that Agile is also needed for their initiatives that are broader in scope and require a significant number of teams.

In this situation, how do we ensure that the multiple teams involved are fully synchronized and working effectively towards a common goal? How do we ensure that they are managing risks well? How do we help ensure the success of the program?

We recommend the following five practices to start scaling Agile:

  • Scrum of Scrums
  • Product Owner Sync
  • Program Backlog
  • Dependency Identification and Scheduling
  • Common Integration Environment

Scrum of Scrums

The Scrum of Scrums is a scaled version of the team’s daily standup. The purpose of the Scrum of Scrums is to ensure alignment of all teams working on the program. Most Agile scaling frameworks (SAFe®, Nexus, Scrum at Scale, etc.) recommend this synchronization event.Scrum of ScrumsThe Scrum of Scrums is held 1 – 2 times per week for 15 – 30 minutes. Each team sends a representative, typically the ScrumMaster, to the Scrum of Scrums. If additional expertise is needed for a discussion, the ScrumMaster can bring in development team members to assist in understanding and decision making. If the multi-team program has a Program Manager, the Program Manager also attends to better understand the inter-team risks.

Topics discussed at the Scrum of Scrums include:

  • Impediments, especially program or organizational level
  • Inter-team dependencies
  • Upcoming milestones
  • Scope and schedule adjustments
  • Integration progress
  • Looming risks
  • Action items

Product Owner Sync

The PO Sync is the content-focused equivalent of the Scrum of Scrums. It is a practice performed even in smaller organizations working on the same platform. The purpose of the PO Sync is to ensure alignment of the product vision and work-related content across all involved teams. SAFe® and Scrum at Scale scaling frameworks recommend this synchronization event.

Product Owner SyncThe PO Sync is held 1 – 2 times per week for approximately 30 minutes. Each team sends their Product Owner to the PO Sync. If the multi-team program has a Program Manager, the Program Manager also attends to ensure the team efforts are cohesive and supportive of the program goals.

Topics discussed at the PO Sync include:

  • Functionality, performance, and interoperability
  • Scope and schedule adjustments
  • Feature prioritization
  • Validation of feature prioritization within the Team Backlogs
  • Coordination and scheduling of inter-team dependencies
  • Team progress on features
  • Decomposition of features to fit within a release
  • Minimum viable product set and minimum marketable feature set
  • Action items

Program Backlog

When multiple teams are working on the same initiative, it is important to establish the Program Backlog. For our purposes, the term “program” is a coordinated multi-team effort. The Program Backlog is a higher-level backlog different than each team’s Product Backlog. The Program Backlog is created and maintained by the Program Manager role or a Product Owner from one of the teams. The Program Backlog consists of features in priority order. All Agile scaling frameworks recommend this artifact.

Teams take the features from the Program Backlog and decompose them into user stories. The user stories then become part of the Team Backlogs. The order of the user stories within the Team Backlogs should reflect the feature priorities. Care should also be taken to allow each team to focus on one feature at a time as serial development is much more economical than parallel development.Program BacklogThe teams then develop the user stories comprising the feature across iterations. In the simplest approach, a feature is developed by one team. In a more complicated approach, a feature is developed by multiple teams, with each team developing their specific user stories while collaborating tightly with the other teams working on the same feature.

Dependency Identification and Scheduling

One of the biggest risks when scaling Agile is inter-team dependencies. To mitigate the risk associated with dependencies, teams working on the same program should plan together (iteration planning and/or release planning) to identify the dependencies between teams. Dependencies can also be removed or reduced by adjusting team composition to be more cross-functional.

Dependencies are bi-directional in that there is both a giver and a getter. To ensure visibility, each dependency should be tracked within the Team Backlogs as either a “Give” or a “Get”. Dependency Identification and Scheduling - "Give" and "Get"

A “Give” is where one team provides a specific deliverable to another team on or before a specified date or iteration. A “Get” is where a team receives a specific deliverable from another team by the specified date or iteration. A “Get” user story will typically involve integration activities across teams.

Care should be taken by the giving team’s Product Owner to prioritize the “Give” in advance of the recipient team’s “Get” in order to reduce the risk of developing both the “Give” and “Get” within the same iteration. As a general rule, the “Give” should be provided 1 or 2 iterations prior to the “Get” integration work. Also when integration work is occurring, the “Give” team should allocate some bandwidth to support the “Get” team with any potential issues found during integration.

Common Integration Environment

Finally, integration is key when multiple teams are developing the same product. You will need to establish a common integration environment for multi-team programs. Ideally, this is done prior to iteration 1 to ensure demonstration of working software from the integration environment each and every iteration.

Typical activities in establishing a common integration environment include server setup, continuous integration (CI) tooling, test case automation, and automated deployment migration.

As in any scaled Agile situation, integration should occur each and every iteration. The true measure of multi-team program progress is the level of integration, not the progress of each team in their local environments. Any approach that defers integration adds an unacceptable level of risk to the program schedule.

 

 

Start small and “think Lean” when considering how to scale Agile at your company. Over time, add in the additional constructs, policies, and approaches on an as-needed basis where it makes sense.

Scaling Agile is a crucial consideration of expanding beyond team-based Agile and pursuing enterprise agility. To ensure your success, call Agile Velocity. We have the appropriate experience in the various scaled Agile frameworks (SAFe®, DAD, LeSS, Scrum@Scale, and others) and can help you apply best practices for your specific needs.

Join the discussion One Comment

  • Bob Galen says:

    Mike, I love the simplicity of this. I agree that these five practices are crucial to effective scaling. It really reflects your experience coming through and not simply recommending one or another framework.

    Nicely done my friend!
    Bob.

Leave a Reply