HiPer Lean: Scaling Agile - 4 Awesome, 3 Terrible Things about SAFe

Thinking about taking your agile implementation further? Have large, complex projects that a single agile team can't deliver? Have complex stakeholder, portfolio and benefits realisation concerns? Consider scaling your agile processes. We'll outline a few and discuss four awesome and three terrible things about the most popular one, "Scaled Agile Framework", known as SAFe.

Frameworks

Here are some others:

• Disciplined Agile Delivery (aka DAD)
• Xscale (CBA's one)
• Large Scale Agile (aka LeSS)

Scaled Agile Framework

Setup by Dean Leffingwell, it's one huge picture: 

Four Awesome Things

1. Training, certification, coaching, case studies, corporate partnering
   • http://www.scaledagile.com/
   • http://www.scaledagileacademy.com/
   • This is excellent marketing and implementation of a market-facing framework. They're a good case study for anyone that wants to take a process concept - Lean Six Sigma, CMMI, Scrum - to market. Take away: Provide organisations with the support that they need to your framework successful.
2. Three-level view
   • Enterprises have been crying out for an agile picture on this for a long time. Whilst I disagree with some the elements of this picture, the general concept that the portfolio level is responsible for the investment, the program level is responsible for industrialisation of the execution, and the team is responsible for the delivery itself is a solid breakdown.
   • Take away: Articulates and demarcates responsibility of the portfolio, program and team levels.
3. Agile Release trains
   • Choo-choo! This pattern, like most process patterns, is not something new - it's the SAFe expression of creating even-ness and fixing the cycle length. This helps reduce mura, waste from unevenness; one of the precursors to a High Performing Team.
   • Take away: Assists in fixing the schedule (as agile/scrum already fixes the people aspect), leaving the only lever to be scope and it's prioritisation. This massively simplifies the project management practice into the Product Ownership practice. This centers the conversation around prioritisation, lean - 'the art of doing only what is needed'.
4. Metrics
   • A framework that puts metrics first? Wonderful. The overall concept is good - make your actuals visible, inspect and adapt to them. Here's some detail: http://scaledagileframework.com/metrics
   • Leaving the concept of PSIs aside (no pun intended), most of the metrics are great - measure a single outcome (velocity via burn downs and release reports) and metricise the retrospective as well as the technical components at each level.
   • Take away: Measurement helps the visiblity-inspection-adapation cycle at the heart of agile, making it a truly empirical process.

Three Terrible Things

Whilst the above makes me sound like a big fan of SAFe, I'm not. Here's why:

• Does away with team-centric velocity measurements and tries to align them
  • This creates further confusion about the use of points, and institutionalises one of the worst approaches. Points were convinced as a unit-free, operational measure, indexed by relative value of a piece of work. It has value in giving the team a measure of productivity tied precisely to value and creates a metrics system around measuring this. It is a team specific measure, utilised to help the team continuously improve.
  • SAFe abuses this notion by trying to equate points across teams, and use them for purposes (cross-team, program level estimation) they were never intended to. This reduces the usefulness of points as a self-empowering metric for continuous improvement; into yet another version of "lines of code", "functional points" and other numbers-heavily, reality-light approach to sizing.
• Does away with incremental and iterative development
  • SAFe suggests that a "Program PSI", which contains vision, objectives and user stories can be defined in such a way so as to pre-plan a series of iterations until their 'capacity is reached'.
  • This boxes in the increments of the product, as the goal must be reached. This constraints and removes the power of the team to create working iterations to test the market.
  • This constraints the experimental nature of the team and prevents them from innovating to deliver anything other than the value as defined upfront, at the start of the PSI. This is anti-agile by design.
• Does way with time-to-market and goes for traditional planning
  • A PSI is a mini waterfall, will all the impediments that this entails.
  • Most of the "agile" part in terms of taking products to market is lost with the SAFe approach.

Summary

Whilst it's neither a awesome or a terrible thing, it's worth mentioning that SAFe has been a massive a money spinner for Leffingwell, with influential organisations coming on board and even big tooling companies such as Rally aligning to it. 

When viewed from a non-agile, institutional lens, SAFe is definitely a "safe" approach. It's not an agile approach. There are reasons why it's successful in the marketplace, which has less to do with the value that it delivers as an agile scaling method than the marketing and support it provides practitioners. It's from a long line of methodologies, prescription heavy and innovation light, helping to entrench 'this is the way we do things, and the way it will always be.'

It's not all bad though. There are elements in the overall picture - a three-level perspective, release trains, and metrics; that are excellent additions to the overall view of agile in an enterprise. So the overall take away from this post - there are scaled agile methodologies; but don't adopt ones like SAFe wholesale.