Why would you want to 'scale' agile?
Tags: safe, agile
Published: 2018-11-02 17:19:59

---
title: Why would you want to 'scale' agile?
published: true
description: Part of a series of articles about Scaled Agile (SAFe)
tags: SAFe, Agile, 
---

This is the latest in my series of articles on trying to understand the Scaled Agile (SAFe) approach. One of the projects I work on has recently implemented it,  and we are currently learning what it means.

Having finally gone round the houses and written articles on [Lean] 
(https://dev.to/mark_nicol/a-bit-more-about-lean-eb), [Agile] (https://dev.to/mark_nicol/a-side-note-on-agile-2f97) and [Scrum](https://dev.to/mark_nicol/some-notes-on-scrum-8im) the purpose of this article is to describe why someone might want to 'scale' agile in an organization.

## Why not just let the Agile teams / Scrum teams do their own thing? ##

This works fine if you have one team, or the teams are not going to end up getting in each other's way. Imagining the scrum model. The teams will each go through the same stages: 

* They will plan work with their customer/stakeholders. 
* They will then select the items they are going to work on. 
* They then work on those items. 
* Once the team finishes they are going to deliver a product to their customer.  

The main chances for conflict come when the work relies on anything outside the control of the team, or on the rhythm in place within another team as to whan they can start work on a given item. However good the teams own planning is, they will fail to complete their work if their priorities don't match. 

Some examples of this might be:

* The team need access to a key stakeholder during their planning but the stakeholder is tied up in meetings with another team.
* The team need a stakeholder to test or review the changes at the end of their sprint. The key stakeholders are however tied up looking at the outputs from a different team
* The features rely on a particular version of some underlying code. Halfway through the sprint the team responsible for that code upgrade the system
* The features rely on a change not yet in production, and the team responsible for that change are late.
* Key specialized operations staff are not available at the point the team is ready to deliver
* Two teams create features that inadvertently conflict
* Two teams are due to deliver at the same time, but both changes rely on different versions of a core platform 
* Key people leave a team halfway through a sprint to because the organization wants to start up a new team.

## What's the simplest solution? ##

Scaled Agle suggests that a lot of these problems either disappear or are at least reduced if: 

### Teams work to the same rhythm or cadence: ###

* Making sure that teams start and stop their sprints at the same time - (SAFe  mandates 2-week iterations. )
* The start and end of each iteration are fixed - if necessary work moves rather than the date. 
* Having a longer timeframe during which the pattern of delivery is synchronized. (In SAFe this is the Program Increment. It consists of 4 working iterations, followed by a planning iteration)
* Changes to teams such as reasigning people happen as far as possible at the end of an iteration.


### Teams have within the pattern time for planning activities and catch up: ###
In SAFe this is the Planning Iteration:

* Teams have a 'planning event' to coordinate and agree on priorities for the next increment.
* The rest of the planning iteration allows time for catch-up. Teams have thinking and planning time. Time to improve tools and processes or to upgrade systems

### Teams have some form of higher level coordination (scrum-of-scrums) to keep the work coordinated during the time they are delivering. ###

SAFe suggests that this works best in 3 dimensions:

* Keeping the organization priorities aligned (a scrum-of-scrums of Product Owners)
* Keeping how the teams work aligned (a scrum-of-scrums of Scrum Masters)
* Coordinating the integration and release of software to the business (the release train)

None of this is necessarily heavyweight or bureaucratic. It is the sort of answers that would emerge naturally from within organizations.

 What Scaled Agile then attempts to do is to polish these ideas into a framework with specific names and roles and some level of rules and rituals.

Tomorrow I'll round up by describing the formal terms and roles in 'Essential' SAFe