Thursday 21 December 2017

SAFe - a second opinion

I had a brief introduction to SAFe at a conference back in 2015. The session focused very much on how in SAFe 100-plus participants come together every 8 to 12 weeks to plan their next delivery commitment. I was not impressed. This to me was the antithesis of Agile.

This week I sat the Leading SAFe course. Was my second opinion any different?

Summary: SAFe does something Very Very Good, something Somewhat Less Good, and something Deeply Troubling.
skip-to-the-end

But first...

What is SAFe for?

The Scaled Agile Framework (SAFe) is for large teams, typically more than 50 individuals, working on a single software solution.

eg 1. One of the course participants was working on a European national train operator's programme to replace their entire ticketing and reservations system. 300+ people, most of them developers, working on a single programme at the same time. (I probably wouldn't structure it like that, but apparently it's working for them.)

eg 2. The trainer has acted as SAFe Programme Consultant on a military system. I don't know which one, but you can easily imagine that a programme to overhaul the systems on the Eurofighter Typhoon might take a dozen software teams several years.

The Very Very Good

In my first encounter with SAFe I was deeply unimpressed with Programme Increment Planning: a 2 week conference, every 8-10 weeks, involving every member of the extended team committing to typically 4 Sprints' work.

Well, I changed my mind.

If we accept that working at scale is something that some programmes just have to do, they are inevitably going to lose a degree of Agility. Can't have Team 1 pivoting when they're working on the same solution as Team 10, or ignoring a dependency from Team 7.

PI Planning is actually a really well designed way to get the teams collaborating. Some key features indicate the genuinely as-Agile-as-possible flavour:

  • Teams plan their own work, based on their velocity
  • Face-to-face discussions between developers across the organisation, to deal with dependencies, ambiguities etc
  • Commitment to Objectives for the upcoming Sprints, not specific User Stories
  • An explicit understanding that the teams' User Stories and plans will change during the forthcoming Sprints (Sprints. Does that sound very Scrummy? More on that below...)
  • A confidence vote towards the end, with an opportunity for team members to raise doubts, risks and concerns

SAFe appears to take de-centralised decision-making, respect for and autonomy of individual team members very seriously. Bringing 100 people together for two days is expensive. But if you're going to have them working on the same overall effort, giving them the opportunity to work directly together every couple of months is a pretty damn good start!

The Somewhat Less Good

So SAFe provides a great way for multiple Agile teams to work together – 10/10. SAFe also has something to say about how those individual teams operate. Actually, SAFe has lots to say about how those individual teams operate.

  • All Scrum teams operate to the same cadence, with Sprints starting and finishing on the same day
  • Teams can operate something other than Scrum (probably Kanban), but they have to deliver to the same cadence anyway
  • Lots and lots of guidance about specific practices: WSJF prioritisation, Lean UX, Story Point estimation and plenty more

SAFE derives these all from their 9 Principles. They're all good principles and it's all good advice – some of the best stuff from the last 2 decades of Agile exploration. But we're moving away from Individuals and interactions over processes and tools (Agile Value #1 for anyone who's forgotten), and replacing it with yet another One True Way.

Look, I understand that SAFe are selling into large enterprises. Some of them don't have any Agile implementation at all and need some guidance, and it is good guidance. (Plus large corporates like uniformity.) But yet another method from the ground up isn't what SAFe excels at and isn't what the Agile community needs. It just seems unnecessary.

The Deeply Troubling

Story Points. Are great. I. Am. Not. Going. To. Sell. Them. To. You. (not here anyway)

Critically, a team comes to their own feel for how User Stories scale for them. Except in SAFe. In SAFe, teams are encouraged to normalise their Story Points: a 3 in my team should mean the same as a 3 in yours. This breaks the cognitive basis of Story Point estimation and the trust put in the team to engage with it. And that should be all I need to say.

It gets worse.

The reason to encourage uniform story-point scaling is so that Product Managers can estimate the sizes of Epics, without consulting the people who will be doing the work, to determine prioritisation and funding. Yes, we're back to software decision-making based on management estimates.

And once more I understand why they've done it. SAFe scales all the way up to Enterprise Portfolio level, and they want to offer a way for senior budget holders to approve pieces of work that could consume many thousands of developer days. And sure it could be done well. But I'm willing to bet that once the SAFe Programme Consultant goes home, these Product Manager estimates rapidly become personal commitments, translated into direct pressure on all those delvelopers or else...

This only exacerbated by the scale of these Epics, reasonably in the range of 1000s of Story Points. A software organisation going through the detail of Programme Increment Planning might be able to come to a reasonable estimate at this scale. For a Product Manager, it can't be anything but a guess.

Conclusions

  • If you have to structure a software programme with 50+ developers, SAFe offers a great Agile way to plan and deliver at scale. Yes there's a sacrifice of agility here, but it's a cost of operating at scale.
  • SAFe also offers its own approach to Agile delivery. This may be a useful starting point for enterprises new to Agile. For experienced practitioners, it may just be overly restrictive.
  • SAFe's use of Story Points should be treated with a great deal of caution. IMO it's a reversion to a damaging pre-Agile mode.

Like any other Agile method, I recommend you take what works for you and leave the rest.

Guy