Do we need a Scaled Agile Framework (SAFe)?

You are with a large enterprise, and your team believes strongly that an Agile Transformation will have a major impact on the organization that will result in greatly improved efficiency and faster time to market. You start from the bottom up; the effort is heavily supported by a few key stakeholders and team members and you make progress. But somewhere along the line, the Project Management Office (PMO) jumps in and attempts to measure results using traditional metrics that do not illustrate the true value of the transformation. So things, unfortunately, fall apart, or more likely are crushed.  And maybe your organization tries again but after the second false start, the support for the transformation begins to melt away.

Does this sound familiar?

Well, this situation is all too frequent and the results can be devastating for companies who really need to transition to Agile. So what is the Scaled Agile Framework (SAFe) and how can it help?

Think of the Scaled Agile Framework as a blueprint for an enterprise system.

What does the Scaled Agile Framework (SAFe) have to offer?

Having this blueprint means we can get to better quality faster and make the appropriate cultural shifts that are required. It helps you map the traditional roles within the organization to the new Scaled Agile Framework roles required for Agile Transformation. It essentially outlines a path to a continuously improving empirical system which, by the way, is what Agile is all about.

By engaging with an agile partner who can work with you to implement the SAFe framework, you can get from “A to B” in a much more efficient and effective way; rather than piecing the steps together over many years, you are essentially accelerating the process by leveraging patterns that have emerged through SAFe’s battle-tested guidance as a result of engagement with an experienced partner.

The metrics are certainly there to prove the value of the SAFe framework. We have seen 10x improvements in quality, productivity, and time to market. There is also far less risk involved since you are moving forward with known patterns rather than a lengthy, home-grown, and undocumented process that may or may not yield results at the end. Indeed one of SAFe’s greatest assets is its normalized lexicon. Everyone can point to the framework and see the Scaled Agile Framework roles, artifacts, and ceremonies and read their descriptions.

The arguments against SAFe

While there is vast momentum with SAFe, there are some detractors. With these detractors comes thoughtful criticism, as well. There are also quite a few harsh comments that come off as bitterness cloaked in “all you need is Scrum” thinking. While no framework is perfect, we must remember that the principles provide solid guidance.

If your organization is large and operates within a complex hardware/software/firmware environment that has been doing things a certain way for a very long time, then it can be extremely challenging to change the way things are done.  Try sending the “Agile Manifesto” to an executive or a PMO with 30 years of experience and see what happens.  Your efforts must go well beyond team-level and be led from the top.  For large enterprise organizations with a hardware pipeline, a plethora of vendors, multiple sites and geographies, and a billion-dollar product stream, just “doing Scrum” at the product level isn’t going to cut it.

I think of the quote by Randy Pausch: “If you’re going to do anything THAT pioneering, you will get those arrows in the back, and you just have to put up with it.”

When you don’t need a Scaled Agile Framework

When you think about whether your company truly needs the Scaled Agile Framework, we look to real-world examples for insight. In the Hewlett-Packard Laser Jet division, Gary Gruver used lean agile principles and short (month-long) time-boxes to achieve faster throughput and responsiveness to remove the Laser Jet division as the bottleneck. Under his enlightened leadership and his “manage to metrics” approach that removed any existing bottlenecked architecture, Gary didn’t require a framework; he had end-to-end control when he needed it.

Additionally, if the scope is well contained or merely technical, you may be able to execute a bottom-up approach.

Then there is the whole element of size. Sure, startups may not require SAFe but there are some key questions to ask before making this determination:

• Do you have more than a couple of teams delivering one or more products?
• Does your organization have more than one time horizon?
• Is there an assemblage of more than one company as suppliers or by acquisition?
• Do you have a huge legacy base in the field?
• Is there an upcoming transition to new projects? 

How to get started with SAFe and do it right

We work with many organizations that have paid a heavy price for taking the piecemeal approach. Project rescues are much more risky, difficult, and expensive simply because once people lose trust, you have lost control of change management. You want to experiment in controlled ways and not jump in without a plan. So take your best shot, invest, and do it well the first time.

Remember that the cultural side of an Agile Transformation is the underlying subtext of everything, and your leadership must be on board and support the urgency for change. “Going back” should not be an option.

It may seem overwhelming, which is why it’s important to engage with a trusted partner who can start with the discovery phase. Your agile partner can then build a tailored plan to include a combination of education, coaching, and advising. They will bootstrap the process, support the initial stab at Agile, implement Scaled Agile Framework roles, and then coach the organization until it is self-sustaining. Essentially, the SAFe framework is like scaffolding; once the structure is in place and everything is operating at maximum capacity, the scaffolding simply melts away.