The SAFe debate goes on (see Lean Magazine #9). Here Eric Schumann, Lean expert at Sellegi, explains why he is a SAFe champion.

In our last issue we described the hot debate about SAFe in the autumn of 2013 where a number of well-known profiles in the Lean/Agile community were very critical of the framework that is supposed to support agile development for large corporations. At the Lean Tribe Gathering in Stockholm we met Eric Schumann from the Swedish company Sellegi, who has worked with SAFe for a while and has just released a tool supporting it (ACT). We took the opportunity to ask him about his view on things.

Your company works with support for Lean and Agile for large enterprises, and has selected SAFe as the framework for your efforts. How come you chose SAFe?

The first time we came in direct contact with SAFe was 2011. When I saw the ‘Big Picture’ it immediately rang a bell. Something like ‘Wow! I have tried to draw this picture for at least 10 years, but never managed it with this excellent combination of clarity, abstraction and understanding.’ I liked the philosophy of forming a framework. SAFe is not a prescriptive model and it gives you the opportunity to cherry pick the sections most valuable to your organization.

The other thing that struck me was the overall permeating pragmatism. This was not a new Scrum certification scam, this was not a new RUP that needs evangelists and religious battles. Deviation is assumed, pre­empted and built in from the beginning.

And last but not least: We have our own tool, Sellegi ACT, that already followed a thinking very much aligned with SAFe (see factbox). We saw that this was a very good fit and that our customers would benefit if we align Sellegi ACT with SAFe and can offer a package of tool, process and training.

How would you summarize SAFe for people not familiar with it?

SAFe is a non­-prescriptive framework of proven practices for scaling lean and agile across the enterprise.

There are some great ideas and blueprints for bringing the benefits of agile from the development team level to product management, release and business planning. Using SAFe will enable most companies to deliver value to their customers more quickly and generate a better understanding of what to focus on across organizational borders.

What do you think are the main strength and benefits of SAFe, and for which type of companies is it useful?

SAFe provides a cohesive overview that can be understood and shared by both technicians and business managers. It also creates the possibility to gather around a common vision as to where the company needs to go. In addition, it gives technicians a better understanding of the business­ priorities and it gives managers an insight into delegated authority and planning. That way it helps to implement the necessary foundation on which agile and lean can thrive and scale. The benefits of SAFe are not in the detail—it is the packaging and foundations that form a  whole which I had not seen described previously.

As such, SAFe can be successfully applied in companies working with fast technical development and a significant software department. It makes it possible to scale the agile and lean benefits across teams and organizations. Any company looking at introducing agile across more than 3 or 4 teams will find ideas worth implementing in SAFe!

One cannot deny that a lot of criticism has been leveled against SAFe. Some say that it is just a new RUP in disguise, and others say that it throws out some of the key concepts of Agile – how would you comment on that?

A common denominator seems to be that SAFe doesn’t forbid you to combine agile with other methods, specifically gated methods. So one theme seems to be: “Do it by the book or do not do it at all”. Often the next conclusion is that SAFe will allow a company to “lock” itself into an ancient way of thinking or sometimes that SAFe is not enough if you want to go “All lean”.

When I think on this, I wonder: Why do you need to go all the way from the start? Some companies I work with are in the production and automotive industry. They can’t just go from zero to full scale in one go. They can’t just throw overboard all the gates needed to synchronize supplier, production and mechanical engineering without risking the company. For them SAFe is a great way to get started—learn, reflect, improve further ­and probably at some point go beyond the ambitions of SAFe and go lean all the way. But for that transition—which can last many, many years—SAFe is a good tool.

This is also true for SW companies which are often unable to fully embrace the whole of agile and lean in one step due to historical, cultural, personal or competence reasons.

So you should see SAFe as it is. It is not Scrum, which is quite prescriptive. Instead, it is a framework which helps you improve. This gives you freedom, and every implementation will look different. Of course that can be scary as well! And it can be abused, but you can’t blame SAFe for the people that may abuse it.

Which, in your opinion, are the weaker parts of SAFe?

For me there are three major weak points:

• The first is the weak guidance on the portfolio level, where you still have to figure out a lot of stuff on your own. There is good content in SAFe, but as yet not enough
• The second is the breakdown chain from business planning (epics), technical roadmap planning (features) to technical implementation (stories). The step from features to stories is too wide, especially for distributed organizations. There is a risk of losing focus on testability of the total system. In addition, dependency management at story level may consume a lot of overhead. Usually we advise our customers to introduce a fourth level for breakdown between feature and story, but that is different discussion.
• The third is the fact that flexibility actually can be a weakness. I love the freedom in the framework character of SAFE. For many companies the level of freedom is overwhelming. For them it might be a good idea to give further examples of pre­packaged combinations that are tailored towards specific, common problems in the industry. E.g. synchronization with technical development

Finally, what do you see as the main challenge for everyone struggling with scaling up Agile Methodologies?

There are now several proven ways of scaling agile and lean in industries primarily working with software. The big challenge will be to bridge the gap into industries with primarily mechanical development such as robotics, production and heavy machinery. There will be a lot to learn from these companies for everyone.