A brief lengthy rant follows on what adoption of the “Scaled Agile Framework” (SAFe) indicates in 2020. For a more comprehensive blow-by-blow of how SAFe is deficient, head over to google. This focuses on the indicators related to the selection of SAFe and not the framework itself.
What problem does SAFe solve?
Agile development took the world by storm in the early 2000s. As is typical of public sector, with an average 20-year delay, agile has started leaking into the public sector in the last couple of years. I’ve written elsewhere about the SDLC in government having contractual and policy ties to waterfall.
As many developer teams in 2005 realized, going to “agile” created a situation where documentation and testing were not done due to the software changing rapidly. This isn’t really a consequence of agile as much as a deficiency in the development team. The solution here is to embrace a few newly-emerged techniques and technologies:
- Open source software
- Automated testing
- Distributed architectures
- other twelve factor methods
These approaches and technologies allow testing to be baked in and documentation scope to be limited and evolve with the application. If a sufficient amount of effort was put into following these approaches and refactoring existing apps, the agile ways thrived and devops emerged.
Sounds great, sounds like nobody needs SAFe, why select it?
Now imagine you’re in an organization that can’t adapt the existing applications into a new way of working. All of the application development requires the contractually-designated gates according to waterfall stages. Iterations that discover necessary changes are seen as a problem rather than a solution. Imagine that pivoting required explaining why the requirements gathering was wrong to a COR or COTR so they could convince a CO to modify a contract or issue a new RFP. Imagine working in an environment where people still think software projects end at “operations and maintenance” rather than “decommissioning”.
Agile development admits that there is no O&M phase anymore. Software is under construction until it is turned off forever. I know a secret though, government (and enterprise) software never gets turned off.
So with an ever-increasing portfolio of applications, no ability to automate testing, no ability to shrink monoliths into component parts, no ability to use open source libraries to accelerate development and improve security, and a thirsty ecosystem of contracts who like to influence acquisitions… what can we do?
The contractor ecosystem had great success at blocking out small businesses who could be agile by inventing a thing called the “Capability Maturity Model Integration.” CMMI is a threshold-based mechanism that prevents boutique software shops from using new methods to enable federal software work. Basically, big expensive projects can only be awarded to organizations with an absurd amount of paperwork.
If Agile becomes desirable, then CMMI is out the window. How will they block out small businesses?
Okay, that sounds really cynical
Maybe.
Is there a more favorable take?
Not sure if this is more or less favorable, but here goes!
SAFe solving real world problems
SAFe assumes agile software development is happening in the org.
The moment a software project starts, it is behind schedule and over budget.
Organizations that create a contract surrounding early requirements create a situation where failing to meet those requirements is cause for not getting paid. Not getting paid is objectively failure.
Scaled Agile Framework empowers an organization to bake these perceived failures into a predictable workflow. The way SAFe overlays scrum and kanban with theories like design thinking and “continuous”-everything is akin to having a waterfall template that has dozens of failed gate reviews. It may be true that the project will have them, but the point is to be able to have constructive conversations around why it’s failing, and after the second or third, maybe re-evaluate if this is the right strategic direction or if some other approaches are necessary.
If SAFe is creating a more predictable framework, isn’t that a good thing?
Predicting failure is different than enabling the proper next steps, or supporting the proper conversations. Especially when that failure comes from process failures. In SAFe, scrutiny of the process itself is now difficult because it’s been baked into the planning cycles and ticketing systems.
Now we have a situation where the developers are working on tickets, those tickets can be reported on by middle managers to see if the developers are on schedule. The decomposed requirements are all traceable through some Epics to stories to manual test scripts. The generated software can be compliance-checked (assuming no-or-limited automation still) and released through a predictable-if-manual process. This sounds great.
The biggest issue I see with this is the false sense of security it provides. The idea that it’s okay to burn so much time and energy on no-value activities like “identifying which solution intent aspects are fixed versus variable” is a problem. Each process outlined by SAFe includes many such no-value steps, much like CMMI. The SAFe organization turns into a paperwork factory at the expense of actually solving problems and achieving goals.
Why is SAFe so popular?
Execs at orgs that select SAFe are typically middle managers who waited out their bosses and are now de facto leaders.
These people haven’t typically had strong feelings on what to do or how to do it. They deferred to visionary leaders before. They are now responsible for what to build but with no vision and no motivation to establish a vision, they look for a way to distribute blame for the inevitable failure.
This is also directly linked to organizations with low psychological safety. Places where bosses scream. The good people leave and the remaining staff are deferential and conservative. No moonshots. No honesty.
Schedule slips are hidden until the last minute. Anything ahead of schedule is quietly slowed down to meet schedule rather than risk losing budget or headcount. Necessary changes in scope are ignored or hidden because those conversations sound like “initial requirements were wrong because of some personal failing”.
SAFe is a process indicator of a dysfunctional org with no vision that is going to circle the drain until a leader emerges… but SAFe will squash that for a while.
No vision? Really?
Strong leadership skills with good vision may not be the core problem, but rather a symptom of the command and control style of doing things in the past. If a strong visionary executive experiences a few big failures, they can become deferential to other inputs. Depending on the organization, it could be a board of directors, external policies, or going data driven where they latch onto any metrics they can find. SAFe can be a metric mill too so plenty of blind adherence to metrics is possible leading to [gaming the system]({{ ref 2020-02-18-trap-wrong-goal }}).
The best way to get out of this learned helplessness is to foster psychological safety. Reframe the failures as learning experiences, and improve feedback from the bottom to the top. Those folks building and using the systems are most knowledgeable about the right steps to improve the systems and organization. If a good stream of honest information is coming up to leadership, vision can be derived from aggregating that information.
These feedback loops can be fostered and leveraged without mandating dozens of no-value activities from an overarching, confusing, and contradictory process.
Either SAFe or psychological safety
In an organization with psychological safety, these no-value-add activities can be safely skipped. There are a set of other activities that take up some of that no-value-add time, but they add value in other ways.
For example, a budget or schedule overrun isn’t a meeting where blame is meted out; it’s the source of constructive conversations. It was also established immediately upon identification of the overrun rather than when it was way too late to do anything about it.
- SAFe developers will work hard to make up time or change scope quietly to address the “problem”.
- Psychologically safe developers view the budget and schedule as aspirations, so identifying overruns is seen as a learning event and is shared immediately.
For the rest of the article, I’m going to rename “Psychologically Safe” to “good” to avoid ascribing a value judgement.
Good teams then, with each passing sprint, reference the initial schedule and budget as a guide to see what should be limited or focused on. It’s important to set the intended spend and expected timeline, but it’s not a commitment to be failed.
We don’t have time for such touchy-freely psychological safety nonsense
If you have time for SAFe, you have time for psychological safety. What you’re really saying is “as a leader, this approach sounds scary”.
Yes, changing an organizational culture can be scary and take time
If you want to hear some examples, the book The Fearless Organization by Amy C. Edmondson outlines several examples. A couple of them are pretty dicey, since she highlights truly evil organizations as good examples of “success due to psychological safety”. The author doesn’t call them out as evil so they could be seen as a model. I think the risk of leaders misusing psychological safety is lower than the negative impact of using SAFe, so the book recommendation stands.
Practical next steps
So what’s the best way to make these conversations productive and positive rather than blame sessions that demand faster development or else?
- Embracing the
failuresand reacting to these as learning experiences - Reinforce the culture by calling out deviations and writing down aspirations
- Empower middle managers and individual contributors to display leadership
There are a range of approaches to implement psychological safety ranging from friendly-handbook-for-aspirations to borderline-psychotic transparency-enabled-abuse. Either of these require a strong leader to model the aspirational behaviors and reinforce them. This can feel like a personal risk to the leader while the reward is typically distributed among all the contributors. It also requires buy-in from the middle managers throughout the organization to act as leaders of their units… which is again perceived as a personal risk without an obvious direct reward.
The classic hierarchy was deferential, where every manager dictated methods and goals down to the folks under them.
The psychologically safe hierarchy has managers that act as conduits for bad news (again, learning isn’t actually bad) and collaboration points. Individual contributors who perform well receive the accolades, and while the organization succeeds together, it feels different.
That sounds tough and risky
Yeah, I hear that. Maybe your boss will retire and you can try doing psychological safety in 2030.