Two years ago I became a SAFe (Scaled Agile Framework) Program Consultant (SPC). Although most of the work I’ve done since 2002 has been in the Agile space, this was my first exposure to Agile at scale. Actually, let me restate that. We’ve scaled Agile at a variety of clients in a variety of ways, but this was the first time I saw someone put pen to paper and really define how to do it.
Shortly after that training, the Chief Architect of a federal agency asked me what I thought about SAFe. Having an only academic view at that point, this is what I sent to him.
My First-Ever SAFe Related Email
At the team level, there is little doubt that the implementation of Agile methodologies, particularly Scrum, has helped transform software development engagements in a positive way. However, once you go beyond the team level and attempt to scale at a much larger level, there is simply little in place to guide an organization in that direction.
To fill that void in the marketplace, the Scaled Agile Framework (SAFe) has become increasingly popular and more organizations are looking to it as an answer to the issues that they are encountering.
Good Things About SAFe (Scaled Agile Framework)
- The framework is very detailed. And, while it is extremely complex, the founders are very transparent and offer a lot of information on their website.
- At the team level, the framework takes the best features of Scrum and XP into account. These are tried and true practices that have proven successful for thousands of organizations over the years, and the framework really celebrates that. So, while this framework is very appealing to executives, it doesn’t forget the fact that strong development practices and teams are important.
- The framework goes beyond the team level and discusses how that level ties in with the program and portfolio. More importantly, the framework is very specific on how it all fits together and is very clear on how to go through the process.
Not-So-Good Things About SAFe (Scaled Agile Framework)
- SAFe has been implemented at some organizations, but the success metrics are unknown.
- SAFe can be overkill. For any given Agile Release Train, SAFe recommends anywhere from 50-125 developers/testers that are working on a single product (or a piece of a product). In our experience, there are simply not that many organizations that have that many developers/testers working on the same product.
- SAFe is a very heavy framework. There is a lot of overhead, the process is very prescriptive, and may be seen as unrealistic to many organizations.
- While SAFe is heavy, the framework doesn’t prescribe a good deal of people to shepherd the process. There is one Release Train Engineer, they suggest that ScrumMasters be split across several teams as well as have work responsibilities within those teams.
So, What’s Happened in the Past Two Years?
A lot! As a frequent attendee of Agile-based conferences, meetups, and workshops, scaling Agile has been the talk of the town. These presentations, and subsequent discussions, have ranged from cordial exchanges to screaming matches. And, it hasn’t just been all about SAFe. Not a day goes by without me talking to someone about Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), Scaling Agile at Spotify, Scrum at Scale, and/or Scrum of Scrums (SoS).
At Excella, we now have six SPCs on staff. We hosted SPC training at our Arlington Tech eXchange (ATX) in February. We are helping a federal government agency implement SAFe for one of their most important programs. But, again, it’s not just all about SAFe. We have LeSS Practitioners on staff. We’re experimenting with other scaled Agile approaches on our engagements. We’re creating training that discusses the good and not-so-good aspects of all the popular scaled Agile approaches. In essence, we’ve immersed ourselves into this world to continually improve ourselves and the clients with which we work.
What I Think Now
Although my understanding of SAFe has gone from merely academic to practitioner-level, the thoughts that I put in that email two years ago remain unchanged. In addition, I’ve witnessed first-hand one more not-so-good thing about SAFe – big bang approaches like this are expensive.
When you look at the “big picture”, the Program level includes several people/teams that are critical to the success of the engagement. Most organizations that I’ve encountered don’t have all these people/teams and it costs a lot of money to bring them in or retool who they have. And, trying to get by without them doesn’t work.
Does this mean that I’m a proponent or opponent of SAFe? Neither…and both.
SAFe is not perfect. None of these approaches are perfect. If you’re looking for the perfect approach for your organization, you’ll never find it, ever.
I would instead continue to stay true to Agile principles, push the boundaries of what’s comfortable for your organization, and continually get better at what you do. Taking an incremental and measured approach to scaling will help you land on what works best for you. That is, of course, until something changes, which we know is right around the corner.