Will SAFe Make you Agile?

You don’t have to look very far to find quite a lot written about why the Scaled Agile Framework (SAFe) isn’t really agile. I am by no means an expert on either agile (or Agile) or SAFe, but having worked in an environment that has adopted it, for over two years, I thought I’d provide my take on it.

Let me just state up front, if you’re reading this in the hope of a definitive answer that tells you whether or not adopting SAFe will make you agile, you’re going to be disappointed.

Secondly, I think it’s really important to just reiterate that being agile isn’t a singular point. Becoming agile is not like trying to climb mount Everest where at some point you will reach the summit and can proudly declare you are now agile (or Agile). Being agile is more like riding a bicycle around a velodrome, it demands balance and effort continuously. Most importantly though, agility is a spectrum.

With that out of the way, let’s get down to business. I want to start off by actually looking at the kinds of organisations that SAFe is targeting (at least in my opinion). I also want to do this without resorting to the usual comparison against waterfall management, as the biggest problem I see with people adopting agile isn’t actually waterfall. Rather, the problems that prevent successful adoption of waterfall, are all to do with bureaucracy, policy and skill sets (and the ability to change them).

I think it would be fair to say that the skills required of an agile feature team are broader than those required of a traditional software delivery team (operating under a “code to this spec please” paradigm). Operating within an agile framework now requires the team to:

• engage with stakeholders (communication skills)
• understand what is required (business analysis skills)
• design the system (architecture skills)
• demonstrate and document the system (communication and documentation skills)

Under other management frameworks such as waterfall, much of this would have been done outside of the team. The obvious answer here of course, is to move those skill sets that previously performed these functions into the agile team. Sadly, it is rarely this simple (I will deliberately omit talking about testing the system here, I’ll come back to that later).

In many large organisations the additional skills referred to above are rarer and seen as more valuable than the ability to write code. The structure of the organisation is also typically such that the development team will not retain these skills. As people show aptitude in these areas, they progress up the management chain or leave to work elsewhere where they are valued within the agile team. The consequences of this are that there simply are not enough people, not only to perform these functions within the agile team, but critically also to be able to upskill the team to perform them themselves.

At this point you’d probably start thinking about hiring new members into the agile team. Depending on the level of bureaucracy in your organisation this is where you’d be blocked for the second time. Companies of the scale the SAFe generally targets will typically have HR departments with very specific hiring policies, pay scales, approved vendor lists and recruitment agencies. Over the last 10 or more years all of these things will have been carefully managed and developed to ensure the company is able to procure exactly the type of person it needed to operate under a waterfall style management framework. The HR department is not only unlikely to have been included into the adoption of SAFe but even less likely to have changed any of those policies to aid in the hiring of people that will be a good fit into an agile environment. Changing those is policies difficult at best (generally impossible) and certainly outside the capability of the agile team.

Hiring is of course, not the only way to augment the team and you’re probably thinking that any company embarking on an agile transformation will have a training budget specifically to address these issues, and you’d be right. The success of any such training will be varied and will depend upon the aptitude of the existing teams, which brings us back to my earlier point; those members of the team who have previously shown themselves to be competent in these areas will have been promoted or left (largely speaking).

This phenomenon actually cuts both ways. Let’s circle back to talking about the testing aspect of an agile team and critically how this differs from the testing that is probably being done in large bureaucratic companies.

In high performing agile teams, testing is not a process that is done at the end of the software development lifecycle. It is something that starts at the beginning and engages the stakeholders to identify the use cases. This input drives not only the functionality that is built, but also the tests that are used to check it performs as expected. A good agile team will ask pointed questions of their stakeholders to drive out the behavioural requirements especially those in edge and failure cases that are often missed or inadequately expressed.

Compare this with a typical testing cycle in bureaucracy laden (sometime referred to as waterfall but in my opinion this label is incorrect and perhaps only shows waterfall when used incorrectly) organisation; in these cases, the testing is deferred to the very end of the delivery lifecycle, often inadequate and usually involves lots of manual steps and following a basic script handed to testers. Over the course of many years of operating in this manner the permanent process of cost optimisation usually results in the testing team being staffed with people of a lower calibre than the development team. Testing is generally thought of as a “lesser” task than the development (and of course this is generally reflected in the salaries too).

Like the problem referenced above with the lack of skill sets in the development team to transition to an agile team, this applies also to the testing team. However, the problem is more complex because there now also the cultural problem of testing being seen as lesser than the development and even if the necessary skill sets for good testing are available persuading developers, architects or team leaders to pick up this work is likely to be fraught with difficulty.

You may now be wondering what is the point of this rather long detour talking about the challenges of adopting agile into well-established large-scale organisations? (I could go on, but I didn’t want to make this an article about the challenges of adopting agile into large organisations, perhaps that’s an article for another day). To highlight that the deficiencies of the Scaled Agile Framework (and I don’t deny there are some), pale into insignificance in comparison to the other problems that any such organisation adopting SAFe will face. Given the challenges outlined above, it seems a little inane to worry about the length of a planning increment or if the SAFe definition of an Epic is agile or not.

If I didn’t know better, I would have said that much that is written about SAFe not being agile, has been written by people who have not worked in large scale, highly bureaucratic, process driven and political organisations. However, having previously worked with the author of at least one of such articles I know this not to be true. While I don’t disagree with much of the critique about SAFe not being the epitome of agility, it is my opinion that much of that assessment really fails to take into account the environments it’s being applied in and the fact that in those situations it still advances these organisations to be more agile than they once were. I find that ironic, really. Agile evangelists and practitioners are missing some of the core fundamentals of the point of agility, to improve the process to result in better software. Each change only needs to make things better, not to solve the problem completely.

Sure, this implies that your organisation may one day outgrow SAFe and evolve to implement a less structured framework, or perhaps develop its own. Much of the criticism around SAFe mentions that while it may be acceptable as a starting point, the fact that there is no literature that talks about moving beyond SAFe rules it out even for this. I’m certainly no expert; I don’t expect the founder of Scrum to provide literature about moving beyond it. The clue however is in the name, the Scaled Agile Framework. It is a framework, and like all frameworks it will need to be adapted to work for you. Not just at the outset but at regular intervals as your organisations evolves too.

Instead of worrying about the size of your epics or the frequency of your PI planning sessions you’d do well to focus instead on whether or not your organisation is falling into the biggest trap SAFe (unintentionally) lays for you. That of providing deliberate constructs to integrate into a non agile company which are then gradually abused to reassert control by the roles that should have been servant leaders. The corollary to the above examples of lack of necessary talent in the agile teams is that the previous holders of power (middle management) will naturally resist the loss of that power and instead of serving the agile teams to remove blockers (such as an HR department that no longer functions as required) will instead become the source of greater friction instead as they attempt to force decisions that should now be in the domain of the agile teams instead.

Are there aspects of SAFe that you need to be careful about as they will lead you down the garden path to agilefall? Yes, of course there are. Will you need experienced agile coaches to help you avoid those pitfalls? Perhaps. Will you benefit overall from adopting SAFe? The answer to that really depends on where your organisation is today on that agility spectrum and how resistant it will be to changing that status quo. Given that SAFe is generally targeting organisations that are quite large, complex and riddled with bureaucracy, chances are that the experiment will fail. Not through any serious deficiency with the Scaled Agile Framework but for the kinds of reasons I outline above instead.

Lastly, I think it’s important to also acknowledge that not every organisation will be able to (or maybe even want to) reach the pinnacle of agile. Some may well never be capable of moving beyond SAFe (for a multitude of internal political or structural reasons), but if that’s better than where they were, is that such a bad thing?

Cycling finally back around to the original question, will SAFe make you agile? In all honesty; no, probably not. Not because of any fundamental limitations with SAFe, but because if you’re the type of organisation that is looking at adopting SAFe (to implement agile) chances are you have so many pitfalls that await, statistically speaking you’re unlikely to be successful. If you’re sure you want to be agile, be prepared to put in a lot of work, invest heavily in your people and if it comes to it, be ruthless in replacing those who are holding back your transformation.