My take on SAFe - Scaled Agile Framework for the Enterprise

Something I’ve observed recently amongst this agile/lean/start up/digitally disrupted community that I’m in, is there are a lot of ‘SAFe haters’ dissing on SAFe out there.

Well I’ve just come from a giant organisation that is actually making a good fist of ‘doing SAFe’, so I feel like I’ve got an experienced based perspective on SAFe which might be of interest to some.

I’ve been chatting to people on this topic, it astonishes me the amount of opinion that is being shared on SAFe. The criticism and the eye rolling and statements about what it is and isn’t. There’s a growing anticipation over how it will be received and perceived at up coming Lean and Agile conferences, the sense of controversy is palpable. I’ve been soul searching over my own recent experiences. Digested into one sentence my opinion is:

“SAFe – it ain’t so bad, but it’s not the answer either.”

So, in what ways do I think SAFe is good and can help?

Lining up iterations amongst several teams.

I’ve observed and executed a few agile transformations, and sooner or later when enough teams are delivering with agility, and enough shared assets are being affected, teams come to the realisation that marching to the beat of their own drum might not be the best thing for everyone and they line up with each others' iterations. SAFe suggests you don’t delay and do this immediately. No harm no foul. It doesn’t hurt anyone and it nicely facilitates some other sharing opportunities. For example, if we all end iterations on the same day we can do a joint innovation day without interrupting any team’s cadence. Wouldn’t that be nice?! For example, if we all start and finish on the same day our reporting nicely rolls up as a set of reporting to our managers. There are a lot of managers in giant orgs, so reporting several teams outputs neatly, as a rolled up set, is probably a good idea. (This of course assumes that managers read reports, perhaps a topic for another day.)

Joining together for planning when things affect each other.

If you are building software that has dependencies on another team, or vice versa and you are doing a planning session, it’s a good idea to do some level of planning in view of each other. SAFe suggests all-in planning of a portfolio of work at an event called a PSI planning session (the acronym has lost it’s meaning, but originally stood for Potentially Shippable Increment).

I’ve attended several of these events now and I find them good opportunities for visibility and sharing. I confess to enjoying the team bonding elements of them also. I personally like being in charge of the ice breaker games so I’m bound to have that opinion. To me there’s not much controversy in the joint planning in SAFe.

Identifying when some teams are smashed, and others are light-on for work.

Don’t you hate being the team that’s under the pump when other teams seem to be having a lovely time of it? SAFe’s PSI event allows this to be in plain sight of aforementioned managers, and gives teams a voice to their problems of too much work and not enough time to meet their commitments. I think this is good. Guess what?! If another team has capacity, they can help you out! Yay!

The benefits of learning from each other.

I don’t know why this was heightened under our attempts at implementing SAFe but we did seem to observe the differences in team’s execution styles more acutely, and we had opportunities for reflection more often, once we moved to the SAFe model. I suspect it’s something to do with the regularity of PSI planning events; you know they are coming, you need to prepare for them, and so you start wondering about what worked last time and what has happened since. My caveat here is that I was a manager, rather than on a team, I think this aspect of SAFe mainly benefits managers.

Surfacing of issues that managers might be able to help with.

As well as the too-much-work problem, there are many issues that SAFe helped us to surface, above the team level, and forced us to act on resolving. I think this is good as I often see teams struggling with how to solve problems that are just beyond the power of the team. A number of times I visited retrospectives to see issues identified that went nowhere. When we had PSI planning, those risks and issues were in plain sight of our GM who really did have the power and influence needed for some of them. I even saw a few busted on the day of PSI planning where he excused himself and got on the blower to people, five minutes later, issue fixed! I think that’s really positive service to provide to the teams.

Would a GM make it to 10 different retrospectives in a fortnight? I doubt it.

So, in what ways do I think  SAFe wasn’t good or helpful?

Cart before the horse problem

We made a big mistake in training people across the board in SAFe before they knew the basics of Agile. We made some big assumptions that when people said “Oh I know Agile” that they knew Agile. Before you could say ‘consultant’ all these people were SAFe certified and attending PSI planning sessions without the first clue about negotiable scope or other basic agile concepts. I had wrongly assumed that training in SAFe would fix the problems that manifested from people sticking to their traditional waterfall guns. But it did not. “That agile team keeps finding new scope!” This was an actual frustrated cry from a newly trained SAFe delivery person.

I wasn’t surprised that they kept finding scope but he certainly was, because he had leap-frogged the basics of agile delivery.

So if you are embarking on a SAFe journey, I suggest you train all of your people in the basics of Agile, it will save your people a lot of anxiety. Em Campbell-Pretty says it better than me, in her blog on training everyone.

The horror of scaling

In large organsiations the enthusiasm for scaling is one that must be continually battled and prevented. You must be a constant gardener of scale, keeping things tight, lean and effective, because there are lots of people hanging around looking for ways to help and they will attach themselves to your stuff in no time. In SAFe there are a myriad of roles identified in what is named ‘The Release Train’. The tendency to want to fill all of these roles with people, whether you need to or not, is strong. I’ve seen several instances of what I think should be projects of 10 people bloat out to 30 at alarming speed, containing no more than the same 4 developers that would have been needed in the 10 person team. SAFe can make us think ‘here are all the roles that need to exist’ instead of ‘here is the work that needs doing’ and before you know it, you are surrounded by more trains than Flinders Street Station.

If you are embarking on a SAFe journey, I suggest you really critically assess the work, decide on the bare minimum people to do the work and build small teams around the work. Don’t start with how many release trains you think you need. A project is still a project and we know it will go better and faster with the least amount of people on it.

Doing SAFe because we have to do SAFe.

The problem with dogmatically applying any methodology is, you soon forget why you are doing it and get caught up in trying to do it perfectly. The problem with that is, people start to avoid you in corridors and now have a label to attach their backlash to. You become ‘SAFe people’ or ‘Agile people’ and also, boring at parties. We should always be asking “how can we be better?” not “how can we be more faithful to a methodology?”. In my opinion this is what was appealing about Agile when I first got into it. You learned the method, said “that’s neat! How can I apply it to my situation?” and tried it, in order to make you better at what you were doing.

Embarking on SAFe? Ask yourself “Why?” a lot. No methodology or framework is a match for critical thinking about your problems and how to solve them to make things better.

Losing sight of other things

When we started building the great digital team we became, inside the giant organisation, we were looking everywhere for inspiration. We were particularly taken with Spotify’s story of how they scaled their organisation’s agile teams to be 30 teams across 3 countries. You, Dear Reader, may also be familiar with the ‘Tribes’ concept of scaling. We took a lot from Spotify that was really successful for us and we enjoyed the focus on people and culture that they championed. 

After that we looked at SAFe for its enterprise grade take on governance and planning at the portfolio level. To paraphrase our Head of Agile Delivery at the time: “I looked at the rest of the organisation, and the types of people, and how much they had invested in their traditional methods and processes, and I knew they wouldn’t let go of that unless I could give them something else.” Quite a smart kid that guy. SAFe certainly answers the call for governance and planning in spades and allowed us to bust through many barriers we had encountered trying to deliver with agility.

However when I, like many others, saw the Spotify video on their engineering culture I reflected on where we started and felt a little sad that we had moved so quickly away from that ideal, and towards SAFe. SAFe and its journey can dwarf everything else very quickly, as it’s quite a commitment to implement.

Going SAFe?

Don’t loose sight of everything else that’s out there. Don’t stop looking to other organisations and methods for ideas. Don’t stop talking to people, reading articles and books or sharing your problems believing that SAFe will be the answer. After all the Agile Manifesto starts with “We are uncovering better ways of developing software” not “Here it is! We found the best way!”.

***

So that's my take on SAFE. Yet another one of those non-silver bullets. It will probably help you with your large transformation if you are in a giant organisation but it's not a license to stop thinking critically about what your organisation and teams need next, to improve.