SAFe or Scaled Agile Framework is probably the most well-known approach for scaling Scrum for larger organizations and projects. While Scrum is the framework, SAFe is the scaling up of that framework. When projects get too large for a single team to handle, the approach is often to use Scrum of Scrums. But sometimes even Scrum of Scrums can't handle the complexity of some very large enterprises and their numerus initiatives that span multiple departments. In these situations, scaling frameworks such as SAFe promise to assist in alleviating the burden.
However, these large scaling frameworks do have some problems that warrant consideration before adopting them, and SAFe is no exception.
Problems with SAFe
In my view, SAFe fails at least one of the four Agile manifesto values: Individuals and interactions over processes and tools. You only need to take a look at the SAFe diagram to know that it does not reflect the reality in the working environment, nor is the level of complexity necessary.
SAFe adds so many unnecessary processes. For starters, the PI (Program Increment) planning sessions usually last 2-3 days, or at the very least slows down effective work for that amount of time. Planning to some degree is necessary, but in my experience the days of PI planning could have be done in a tight, focused half-day session, or at the very most one day, with "back to normal" work starting on the next day. This was never the case in my experience, with the day following PI planning as a kind of holiday from the actual activities associated with the objectives agreed upon in the PI.
Then there are meetings. When I worked in a SAFe environment, every day there were meetings to discuss program or portfolio initiatives. It begs the question, are initiatives at the program/portfolio level changing that rapidly that they need to be discussed with the team every day? How about a daily project-level or stand-up meeting (which were basically non-existent); wouldn't that be a better use of time and resources?
This bring me to the second of four values in the Agile Manifesto that I believe SAFe may fail: Responding to change over following a plan.
As mentioned above, the PI planning sessions in my experience are far too long, lack substance, and are not reflective of the realistic work activity that occurs during the PI and sprints. For example, a large portion of time in the PI planning session was devoted to creating story cards for each project. These story cards were rarely followed nor reflective of the actual work being performed. Rather than the team having input to these story cards, they were left to the project manager of each project, which in a SAFe environment, was the same thing as a Scrum Master. The disconnect between project story cards and workplace reality was no more evident that the daily stand-ups in a SAFe environment where the program/portfolio level "cards" were discussed ad nauseam, but not the individual project level cards. Further, the program/portfolio level cards were created by the Release Train Engineer (RTE) and Delivery Lead with totally different terminology and priority than the teams used in their own project cards. I used to watch the blank faces of these project managers counting the minutes so that they could get back to something valuable, like running their own projects which they now had 30-60 minutes less time to do. These program/portfolio meetings and planning sessions were mandated by the RTE, which brings me to another problem within a SAFe environment: The Release Train Engineer (RTE).
From my experience in Australia's biggest university which had adopted SAFe a few years earlier, the RTE role is a complete waste of time. The normally servant-leader role and roadblock remover was in fact a major obstacle to team innovation and agility, but even worse, it was a purely autocratic role. The reason this can happen in a SAFe environment is because the RTE is left un-checked by way of their Agile expertise. They may have a manager yes, but that manager is usually not an expert in Agile ways and certainly not SAFe trained or certified. This gives license for the RTE to make bad decisions and rule people and processes without recourse, especially if the organization has mandated a SAFe environment. The keys to the SAFe kingdom sit squarely with the RTE. The basic construct of SAFe is the Agile Release Train and so that train is not going away. However, creating an emperor of that train takes away from the usual collaborative team approach in Agile. What I observed were project managers that could have enacted the program/portfolio initiatives set out by the Delivery Lead, but instead were bogged down by the rules, processes and mico-management dogma the RTE.
These are just a few of the observations I made after working in a SAFe environment, which by every measure had full enterprise support, a massive budget and keen Agile professionals. But the veneer of SAFe and the overlords who sung its praises was not persuasive enough in the light of obvious loop holes in the framework; certainly at this institution. Over time, I spoke to 3 of the 6 project managers in this SAFe environment and was surprised to discover their level of disdain for SAFe for the same reasons cited above. Their opinion cannot be overlooked, since as I said earlier, project managers are not only scrum masters in a SAFe environment, they are often product owners as well.
Which brings me to perhaps to the biggest issue in a SAFe environment if not managed correctly. Very often, only one person plays the role of project manager, scrum master and product owner at the same time. When you have this triple role played by one person, and that person reports to the RTE who has become the biggest roadblock of all, the road for SAFe seems very unSAFe indeed.
Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!