Scaling agile: the SAFe case

As we mentioned previously, scaling Agile is not that easy and the difficulties multiply as you add teams and people. The secret is to keep it simple and gradually add practices that are still connected to the core agile principles.  Do not fall back into the old practices of command & control! That being said, it is helpful to have a “set of patterns” that assist organizations to scale. So, I thought I’d mine one of the most popular scaling frameworks for some patterns that I feel are useful and that framework is SAFe, which is becoming the leading Scaling Agile framework.

SAFe overview

SAFe® for Lean Enterprises is a knowledge base of principles, practices and competencies; it builds up on the Agile manifesto but takes many concepts also from the Lean, Systems Thinking and DevOps approaches. Since they have a strict content sharing policy, I will not copy anything outside their Introduction here. You can find the SAFe principles on their site and you can see it’s  a mix between Agile and Lean, which should be very familiar to you now. (add link and maybe image). Possibly their most interesting principles for a scaled approach are:
  • take an economic view
  • apply systems thinking
  • organise around value
The Core Values are also quite familiar and they are:
  • built-in quality
  • program execution
  • alignment
  • transparency
The picture below describes the essential configuration, the simplest configuration that provides the basic elements of Safe.

Image  © Scaled Agile, Inc.

The Agile Team

Like many other frameworks, the Agile Team is the core of SAFe. In fact, keeping the team front & center is fundamental for the project success. That includes values like: self-direction, autonomy, trust, psychological safety, etc. Agile Teams in SAFe are cross-functional teams, organised around value, with all the skills necessary to develop increments of value in a short time box. That said, what methodology to use at team level is free to choose for each team: it can be Scrum or Kanban or a mix of the two (Scrumban) or can be XP.
There is a special focus on built-in quality (it’s one of the SAFE core values) and technical practices – such as the XP SOLID – being leveraged with the teams (Team and Technical Agility). One of the most important preconditions to scaling is having solid, mature and healthy agile teams to build upon. As usual, each team has their own backlog (Team Backlog) which represent opportunities and not commitments and organise the work in time-boxed iterations. No big differences here.

Differences: Scrum Master

In Agile Scrum the Scrum Master is usually a full-time role. However, at enterprise scale, it can be a challenge to sell the need for a full-time Scrum Master for each Agile team. It probably isn’t economically or politically practical to take dozens of full-time development team members and assign them to these duties—duties that don’t include development or testing. Therefore, SAFe takes a pragmatic approach and assumes, in general, that the Scrum Master is a part-time role. Possibly more intensive during the initial adoption phases.

Combining Teams into an ART

Collaborating with other teams is one of the major pain points when scaling up Agile and SAFe aims to solve it by planning and having a common Program Increment (PI) and by syncing the teams’ iterations to create a unique release tempo (a Release Train) across a set of teams doing related work.
Building enterprise-class solutions typically requires more scope and breadth of skills than a single Agile team can provide. Therefore, multiple Agile teams must collaborate.
The Agile Teams are combined into a virtual long-lived self-organising team where they operate on common principles. This virtual organisation of Agile teams (typically between 5 and 12 teams which means between 50 and 125 people) is called in SAFe an ART: an Agile Release Train. An ART aligns teams to a common business mission to incrementally and continuously develop and deliver solutions in a value stream. Iterations are still the basic building block: a time box where Agile Teams deliver incremental value but they are combined into a Program Increment where the ART Team delivers its incremental value. Here is what happens in each Program Increment for the teams (there are four kind of event that deserve to be explained in separate posts):
  1. PI Planning event: this is the planning event before each PI starts. Teams plan their work at this periodic, large event; this is a beefed-up version of a Sprint planning. All teams commit to a set of objectives to be delivered in the PI, both at team level and at program level.
    • Every n iterations a Program Increment is planned and concluded. Typically a PI takes 8 to 12 weeks, which means (if the iterations take two weeks) a PI has 4 to 6 iterations.
    • All iterations are time-boxed, have a common length and start/end dates (they are synced for all teams).
    • Teams develop on cadence: every iteration each team delivers a working, tested and potentially deployable increment. And release on demand (typically at the end of the PI).
    • all the iteration’s deliverables are reviewed with the stakeholders who provide feedback. This is called System Demo and is very similar to a scaled Sprint review.
  2. ART Sync event: this is a coordination and synchronisation point happening mid way; the teams on the ART sync regarding the progress of the PI. These coordination points are similar to a Scrum of Scrums.
  3. System Demo event: after each iteration, all the deliverables together (full-system) are reviewed with the stakeholders who provide feedbacks.
  4. Inspect and Adapt event: The ART reviews and improves its process before the next PI.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s