Perspective: Looking at SAFe through an SE Lens

10-27-20Andy Skotnicki
Andy Skotnicki

Is SAFe compatible with Systems Engineering?

The execution of Systems Engineering has been broken for a while. That’s a bold statement, I know, but likely not a surprise to anyone. So how can this be? We have more Systems Engineers today than we’ve ever had. Haven’t we made any progress as a discipline? This article explores one of the outcomes of this dilemma, specifically the recent push to adopt the Scaled Agile Framework (SAFe) as a part of government pre-acquisition Systems Engineering and Technical Assistance (SETA) type contracts. These contract are often focused on helping the government pursue and award follow-on development (acquisition) type contracts, if done effectively.

Before addressing the impacts of adopting SAFe, let’s first explore why we may even be considering this DevOps based/originated methodology. Many years ago at a local symposium sponsored by a prominent System Integrator in the DC area, the lack of actual Systems Engineering (the “real” engineering, vice process) competency was described as “the single biggest risk to national security.” This was obviously a bold statement, and while there are many symptoms and associated outcomes that can be listed here, the root cause always seems to come back to not having sufficiently trained, mentored, and experienced engineering leadership on solution-based contracts, especially as the need for this skillset exponentially grew over the last 3 decades. Actual Systems Engineering has been spread so thin, or being performed in name only, that customers are often questioning its value on many programs, instead depending more on developers than ever before. That has had impacts over time, from what work gets emphasized and to how it’s performed. Even though I eagerly concurred at the time, about 15 years ago, it seems even truer today! How did we get here? Although only based on my direct observations across my career, including government service, I believe it all started with government downsizing in the mid-90s, as part of acquisition reform initiatives. While the government struggled to do more with less, the dynamics of the government-contractor relationship changed, creating an engineering leadership vacuum that many contractors were not able to compensate for. It has become a tightly coupled vs loosely coupled kind of a relationship; most developers enjoy the latter. The reduced government workforce set expectations of followership rather than leadership on their contractor staff. This led to a great number of contractors becoming more and more reactive, more process focused, and more subject matter expert (SME)-based over time, having essentially lost their ability to get ahead of “the problem”. This enables “shiny widgets” to be viewed as quick fixes for various symptoms that are often observed in today’s environment, but don’t really address their underlying root cause. One of these “shiny widgets” is SAFe.

This article is not intended to describe SAFe; there are many online resources for that purpose. The intent here is to determine the role of SAFe on government SETA type contracts that don’t do development, and if so, how it could be tailored for a non-development environment to deliver value. The general belief seems to be “If it works elsewhere (DevOps-type contracts) why can’t it be “cut and pasted” to work here?” (SETA-type contracts)? Well, the answer is complicated because Systems Engineering is complicated in execution. The intent of Systems Engineering is to effectively manage complexity, risks, and offer a clear path to successful system (not just software) outcomes. But are the outcomes of SAFe compatible with higher-level Enterprise Engineering and Systems Architecting/Engineering needs? SAFe offers a framework and methodology, from Enterprise to development levels, at least for DevOps-centric efforts. If tailored, this is not necessarily a bad thing, but many programs/projects are just bulk adopting SAFe without understanding what they’re compensating for. SAFe may seem more inclusive on the surface, but Systems Engineering has always been capable of addressing multiple levels of engineering, if expertly tailored, but as competency has continued to decline for several decades now, such tailoring is no longer commonplace. SAFe does a good job of consolidating many lessons learned from the engineering and development communities, and while SAFe may not have specifically created most of them, it’s nice to have them in one place as reference. However, some of these lessons learned fall into the common trap of misinterpretations.

One example is the failure of the classic Waterfall/V-model to address modern challenges, while also not acknowledging that there are several other approaches/models based on risk tolerance (e.g., W, N, Z, Spiral, etc.). This misinterpretation is only one of SAFe’s justifications for Lean-Agile. This is not an argument of right vs. wrong, but it does depend on specific customer/product application. At the center of the SAFe standard diagram, in very small font, includes the need for Systems Engineering, specifically Model-Based Systems Engineering (MBSE) and related Systems Thinking for SAFe to actually work as described – interesting. This is not surprising because the Software Engineering community has always taken the best of Systems Engineering to improve their own discipline. For example, Software Engineers (SWEs) refer to Use Cases, Epics and Sprints, while in parallel, SEs refer to System Threads, Effectivities, and “I don’t care how you implement” (with respect to sprints). Unfortunately, MBSE execution doesn’t seem to be well understood within SAFe since it isn’t well understood in the broader community, which can lead to a current weakness within the SAFe methodology, it’s Achilles heal. SAFe does do a better job of delineating responsibilities at each engineering level, in a generic way, but it does so by replacing all the Systems Engineering terminology, often leading to immense and unneeded confusion. Added to this is the assumption that many non-developmental engineers must now become SAFe certified, an Agilist to add to our growing list of certifications.

So, do we on SETA (and even most system development) type contracts have to throw everything out and start over? Have we had it wrong all these decades, or worse, become antiquated? What is the guarantee that SAFe (methodology/processes) will provide better outcomes than System Engineering methodology/processes? The short answer is, it depends. It depends on whether we think we’re trying to supplement or replace a methodology/process problem or an engineering problem. As stated in a previous article, Systems Engineering is comprised of experience-based architecting/engineering, as well as related management processes. If we’re trying to supplement methodology/process, then let’s talk specifics and develop a plan to incrementally address shortcomings over time. There’s already significant overlap between a well executed Architecting/Systems Engineering methodology across multiple engineering levels and a highly tailored SAFe methodology (potentially) that will draw any legacy execution issues to the surface. If we’re trying to supplement/fix Architecting/Systems Engineering, SAFe will likely not offer any significant benefit, much like Cloud migration without first understanding legacy software design and associated interfaces.

Arena Technologies understands Architecting/Systems Engineering fundamentals and has the expertise and experience to help our partners and customers integrate one or multiple levels of engineering into a normalized and aligned set of activities that are inherently lean-agile. This can be done with a multi-layered Systems Engineering approach (everything is a system within a system), or by understanding the appropriate role of SAFe Lean-Agile principles on SETA-type contracts, or both at the same time depending on types of development within the same organization.

Leave a Reply

Your email address will not be published. Required fields are marked *