Blog

Webinar Recap – Scaling Agility: 5 Practices to Get Your Organization Started

By: Agile Velocity | Jun 29, 2018 |  Agile Transformation,  Leadership,  Webinar

 

In this webinar, Mike and Bryan discussed different tactics and practices that organizations can take as they begin to scale agility across the organization. You can find the webinar summary and Q&A transcription below.

Summary

Start Simple

There are a number of really good Agile scaling frameworks out there–SAFe, DAD, LeSS, Enterprise Scrum, etc. Some can appear overly complex and scary at first glance.

Start simple. Don’t immediately align with any specific framework. There are some common best practices that most of the scaling frameworks out there recommend, so just start there. Then evolve and grow over time by adding a bit more here and there as your organization’s needs dictate it.

5 Practices to Start Scaling Agile

  1. Scrum of Scrums

Chances are you are familiar with the Daily Scrum that is held every day within the Agile Team, to synchronize efforts around the plan for today. Scrum of Scrums is a scaled version of the Daily Scrum – to ensure that the cross-team work is synchronized.

  1.  Product Owner Sync

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 @ Scale scaling frameworks recommend this scaling event.

  1. Program Backlog

When multiple teams are working on the same program, it is important to establish the Program Backlog. The Program Backlog is created and maintained by the Program Manager role or perhaps even a Product Owner from one of the teams. The Program Backlog consists of features in priority order.

  1. Dependency Identification and Scheduling

One of the biggest risks when scaling Agile is inter-team dependencies. To mitigate these risks, teams working on the same program should plan together (iteration planning and/or release planning) to identify the dependencies between teams.

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” as shown in the diagram.

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.

  1. Common Integration Environment

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
  • Network access
  • Continuous Integration (CI) tooling
  • Source code repository program mainline branch establishment
  • Test case automation
  • Automatic deployment migration from local to integration/staging environment

 

Questions from 5 Practices to Begin Scaling Agility Webinar

  1. Where does the security testing occur on slide 14? Is it assumed to be part of the unit & validation tests?

Yes. In an Agile organization, security concerns need to be considered as we go within each iteration. This leads to unit testing and functional testing for the security requirements.

  1. What is your recommended “planning” approach for a given development timeline (e.g. 6 weeks or 1 qtr)? Specifically, getting ahead of cross-team dependencies.

I recommend quarterly release planning with an emphasis on identifying dependencies and making them visible. SAFe has an excellent technique for this called the Program Board.

  1. Are the % usage of SAFe vs LeSS vs others just in the US or across the world? I have heard the LeSS is more commonly used in Europe and possibly Asia.

The cPrime survey referenced received responses from all over the world.

  1. Understanding there is a Scrum of Scrums (S2), what are your thoughts on scaling that further to a “Scrum of Scrum of Scrums” (i.e. – S3) or even an S4? We’ve seen this implemented to create sync points across multiple trains (S3) and value streams (S4). Thoughts on this?

Scrum of Scrums is definitely fractal and can be scaled up as needed. Specifically, a “Scrum of Scrums of Scrums” is useful in coordination of large solutions involving multiple programs (or Agile release trains) as you mention. I personally have never seen it beyond 3 levels (S3), but it is theoretically scalable to the nth degree.

  1. What works best for Scaling, Scrum or Kanban?

Both can be scaled. Many Kanban teams take a “Scrumban” approach by including some best practices of Scrum–in particular, the Daily Scrum. Thus, scaling up to a “Scrum of Scrums” is a natural extension to the daily planning event.

 

If you’re looking to start a SAFe® implementation, we recommend starting with Leading SAFe® training. You can explore our public and private training options on our Leading SAFe® training page by clicking here

Leave a Reply

Your email address will not be published. Required fields are marked *

< Back