It's still about agile teams

With all the ranting around SAFe recently, I want to address one of the most common, and likewise most severe, dysfunctions in many SAFe implementations: The lack of a solid foundation in agility.

To make my point, I will take a heavily biased stance, and I am fully aware of the bias I present.

Cracking the crust paved by traditional organizational structure requires patience - and it's a slow process.

Why SAFe sucks

We start with a hierarchical organization that wouldn't know Agile if it slapped the CEO right in the face. Then, we bring in a swarm of consultants, do some Leadership training. Everyone's excited. Management huddles together and conceptualizes the new hierarchy, called "Large Solutions" and "Agile Release Trains".

When this is done, we select the members of the new hierarchy, called "Train Engineers", "Architects" and "Product/Solution Managers" and train them for their new role. All of them have been selected based on their importance in former power structures, giving each of them at least as much power as they had before.

Once that is done, we forcefully rearrange formerly functional teams in order to meet the new structure, which relabels "departments" to "value streams", "project managers" to "Product Owners" and "Team Leads" to "Scrum Masters". Off for another round of trainings, also including team members for two days and then ...

We do a PI Planning where the Waterfall Agenda is presented to the teams and then everyone has to created a detail upfront plan and commit to management's unrealistic expectations.

Done. Well, almost. Teams now report and get tracked against their 2-weeks micromanaged commitment until the next PI Planning, where the last plan is supposed to be finished.

That's the Real World!

It would be a lie to say I haven't seen this happen. The amount of dysfunctions in this approach are so numerable that it would take hours to list them all out.

Here are just the few biggest problems with the approach:

1. SAFe is considered a management methodology, not a development approach.
2. Management buys into something they didn't even understand.
3. Developers were never asked for their opinion.
4. SAFe was immediately adjusted to preserve the existing system.
5. Mindset never changed.
6. SAFe was introduced as a structural change, not as a way of changing how value is produced.
7. No effort was made to even attempt and understand what "Agile" means.

Is this the fault of SAFe, neglect on management side, time pressure or some evil consultancy's attempt to screw over someone for a quick buck?

I don't know, and I will not argue, because the issues described are generic and root causes could be different in different places. 

The basis is still the Agile Team

What people forget: SAFe is quite clear that the basis of an Agile Release Train and the SAFe organization is still an Agile Team.
SAFe is the only agile framework which does acknowledge that Agile Teams can have their own, individual mode of working that may or may not coincide with Scrum, XP or Kanban - the only constraint is that the team needs to be agile!

Sadly, organizations do not invest into team level agility before pushing in SAFe. For whatever reason - SAFe oftentimes becomes a dysfunctional relabelling exercise because no effort has been taken to agilize teams.

The illusion of fast results

While Agile teams can deliver high quality Working Software in short cycles, the amount of effort required to bring a team to this level is immense. Many times, management just declares, "We are now Agile" without investing into team building, sustainable engineering practices and agile mindset.

This doesn't work and it will be a flash in the pan. Results will remain elusive, as the organization will effectively accumulate further organizational debt without addressing the underlying issues.

Teams do not become Agile by declaration, and they also do not become Agile by pushing a framework like Scrum or Kanban onto them.

Investing into Agile Teams

Agility is a slow, challenging process with a long and steep learning curve. A two-day training is not much more than waving the "Go" flag on a race track, and some organizations are even cutting corners there - thinking that "it's already enough when we sent Scrum Masters to training": NO!

To be agile, a team needs:

• Operational Excellence
• Technical Excellence
• Drive (ref. Dan Pink)

Based on my experience, the willingness of organizations to invest time and money into these items decreases exponentially in descending order of the list, and it often starts at a staggering low.

Raising Agile Teams

Agile teams are in little need as by definition, they are already self-organized, understand their domain and deliver amazing results. When a team isn't described by these three attributes, they aren't agile to begin with and do not meet the minimum requirements for a SAFe organization!

Teams that are not on this level need a lot more care and support.
Some of this is achieved by management action: changing processes, structures and constraints in order to enable the teams to get there.
Another big enabler is coaching: working with the teams, helping them discover the necessary means  to take control of their work and adopt the practices which help them deliver excellent results.

Coaching is a slow process. It can't be done in a day or two, and workshop sessions - while indeed helpful for specific aspects - aren't sufficient to establish a new culture.

Unfortunately, many organizations invest insufficient time and budget into the necessary groundwork for raising agile teams. Is it suprising then that teams - and ultimately these organizations - struggle?

Sustaining Agile Teams

Agile teams stay (and grow more) agile when their environment supports agility. When an agile team is shoved into a non-agile box, the constraints will force the team to reduce their own level of agility to meet external constraints. 

When SAFe is adopted carelessly, imposing non-agile constraints on otherwise agile teams, the organization's overall level of agility will be limited accordingly. 

In order to get the most benefits out of SAFe, the question should be more along the lines of "Which organizational constraints become superfluous or redundant due to having a SAFe organization", rather than, "Which constraints do we need to add on top of a SAFe organization?"

When organizations abuse SAFe in order to introduce impediments to team-level agility, poor outcomes are the logical consequence.

Nurturing Agile Teams

Agile teams will find a supportive environment highly beneficial in order to deliver even higher business value. Where individual agile teams oftentimes struggle at arbitrary organizational boundaries - from fixed department structures to other "autonomous" agile teams - organizational change, overarching alignment and the occasional global optimization at the expense of local autonomy are indeed a benefit to systemic agility.

SAFe can then be used to provide minimal guiding structure to teams operating in larger environments, referring to common patterns addressing challenging systemic impediments.

The very reason for having experienced SPC's on board would be to both stop the people who lack agile experience from over-engineering upfront, and then pointing out exactly those SAFe patterns which can be considered when a systemic impediment becomes significant.

Unfortunately, we see too many organizations pre-conceiving "the perfect agile organization" as fast as possible and as closely as possible to the SAFe Big Picture - and then implementing it by following a plan without responding to change (which never works).
Managers are quick to proclaim that certain solutions are needed when no team has raised an impediment, and thus un-necessary structure is implemented on a whim.

Agile Management

You can't manage agile teams without being agile yourself. Before managers have changed their own mindset, attitude and understanding, they will not succeed at creating an agile organization at scale.

Most managers fail at the very simple exercise of becoming agile themselves in order to serve agile teams.

Management failure occurs at three levels:

1. Thinking that "Agile" is for development teams only
2. Limiting "Agile" to IT
3. Not investing time into changing themselves

Until management comes to see their own role in the current system, and that change relies on them lifting their own anchoring of an old status quo, agility will remain a fluke.

Management philosophy and practice change is essential for SAFe to result in an Agile Organization.

My Advice

SAFe without a foundation of agile teams is madness.

SAFe driven by the organization without considering agile teams is pointless. 

SAFe imposed by management against the will of teams is craziness.

When an organization does these things, any SAFe initiative is pretty much doomed.

My advice is to take the following steps:

1. Establish agile teams to begin with. If you can't do that, don't even think of SAFe.
2. Invest as much into your agile teams as needed. If you aren't willing to do that, SAFe is waste.
3. Create an environment where your agile teams can thrive. If you think you can't, SAFe isn't going to improve the situation.
4. After you did 1-3, seriously consider which challenges you want to address and where your teams struggle. Do not introduce SAFe as a solution to problems you don't have!