SAFe: Scaled Agile Framework… vom…but…

The additional “e” making SAFe “safe” is an excellent marketing consideration. SAF + “e” is safe to do. SAFe adds a level of safety by lowering risk.

What is it?

It is a guide of things to do for large development teams to work in an agile way.

When I see guide, I mean it. It has descriptions on what meetings/ceremonies you should have, what each persons role responsibilities are, and how each member should be able to connect with one another.

When would you want it?

Because managing 50 developers can be difficult, especially if they don’t work as one team.

Large corperations/organisations have a lot of developers working on a lot of related and dependent things. Working in a typical waterfall* way can cause large problems — specifically in addressing what customers want and having to retroactively change. At it’s core agile* methodologies are made to address this and allow development teams to iterate and ship products early. The problem is that Agile ways of working were built and defined for small teams (daily stand-ups, pivoting if an when necessary, anyone should be able to influence anything).

This can be a tricky thing to manage as more and more people get involved. You could silo people into smaller teams but then it can be difficult to ensure they communicate well.

SAFe is a framework that has been designed, regularly iterated and improved to address this large corporate need. It is especially prevalent as more and more non-typical organisations become more tech focused.

Okay can you give me an overview?

Sure — there are 4 levels which can be collapsed if needed: Portfolio, Solution, Program and Team.

Let’s assume we are in the largest of large companies. At the highest level you have the Portfolio — your ‘people from on high’ or ‘helm of the ship’. Enterprise Architects and the ‘strategic’ people defining what the business should be doing. In some rough way, they influence the direction of development. At some point someone high in Apple said ‘Could we make a phone?’ and someone in Monzo said ‘Can we operate in America?’. After, they kept pushing and supporting that move.

Note: It doesn’t matter who’s idea it was, ultimately the steer came from here.

Next is the (Large) Solution team — the ‘okay we are making an X but what do we need to do?”.

In this level, SAFe says you need 3 things: the tech side (understanding, coordinating and directing technical), a product side (understanding, coordinating and directing product) and a operational side (facilitators). I think of it like this, it makes sense a company would have a CEO, a CTO and a COO (Chief Operating Officer). One says what to do, the other two say how to do it.

The Program level is more focused on developing and delivering a part of the overall solution. Similar to the Solution team, the trifecta of skills is needed — Product, Tech and Operational. The main difference here though is cohesion as this Program team needs to interface with all the teams that go below it. SAFe suggests somewhere between 5–12 teams and hence it could be over 100 people — which the Product team are accountable for helping work together, deliver value and align to wider companies vision from the two groups above.

The Team is where it is easiest to see value being delivered day by day. The trifecta of skills are still needed and hence you should have the team of devs (tech), a product owner (product) and a scrum master (operational), working every day add value: bit by bit, story by story.

Now this structure is kind of obvious, logical and, dare I say it, not hugely unusual. I think the most ‘new’ feature of the structure is the focus on having product people directly with the dev in teams.

Teams work as normal agile teams in many ways: same ceremonies (daily stand ups, retros, sprint reviews, etc.), ability to release on demand, small mixed skilled teams, continuous improvement, what good practice looks like for stories, etc …

It demands focus on communication and alignment of everyone

The most interesting thing is in how teams are suggested to work with each other — a large responsibility falls on the Program team in organizing, directing and facilitating this communication.

SAFe suggests Program Increment Planning— demanding everyone in the teams (all 100+ people) to get into a room together and learn, mix and communicate.

It suggests other ceremonies but PI planning is perhaps the most distinct and potentially valuable. ‘I hate meetings’ I hear you say and yeah, I agree. This is less like a meeting and more like a day of learning — learning how the program is going. Teams show off what they have done, you see the value of what people are doing, there are discussions on whats coming up or are worth knowing and then you as a 100+ person team start planning the next could of weeks (typically 8) but now you have the ability to walk over and ask the person your work will be dependent on if they are on the same wave length. You now know the person, have had a nice relaxed chat maybe shared a snack and can rely on one another.

At the end of the planning (typically two days) you as an individual no matter what you do know on some level what has been done, what needs to be done and who you need to get that done. After, as a group you have a retro to make the process better the next time.

Yes it is a huge commitment, yes it is expensive in effort, yes to what ever else you don’t like about it, but do you know how much waste there could be with people not understanding what they are doing (and hence not sharing ideas), not talking to others, and not feeling comfortable to share true information with each other.


There is a lot more detail, suggestions and best practices, but these were the ones that stood out. Another thing I have found useful since the training and then the further study and certification, is the ability to say ‘you know this isn’t/is in SAFe?’. SAFe has verified what is some costly practices which previously people may have laughed off for wasting time but now, just because SAFe says it, shouldn't be argued with.

Is it actually being used?

The SAFe site does have a case studies section (Accenture, LEGO, FitBit, Sony and others), and while at IBM, many clients used it rigidly. I experienced it swiftly in Telcos and Banks. We are now using it an dunnhumby. It seems to have a real uptake with companies which aren’t typically tech companies but are transitioning to be. Why? Well it is a good rule book. Is it perfect? No but it is constantly being revised. Will it solve everything? Obviously not.

Is it everything it is marketed to be?

The additional “e” making SAFe “safe” is an excellent marketing consideration. SAF + “e” is safe to do. SAFe adds a level of safety by lowering risk.

Is it useful though? Definitely, yes for us.

Anything else?

One other thing I wanted to mention was that location is mentioned within the framework. The space you work in should help you work — a nice place to be, space for conversations, referenceable material (personas, roadmaps, metrics, workboards). Another critical thing with space — access to your team. You should be able to speak to any and everyone AND them hear you, everything should be open.

Both are critically ignore all too commonly.

Founder of and Product Owner @ dunnhumby; just genuinely interested in a lot of things. Built racecars, built electronics, now building software

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store