Governance in SAFe

At its best, a governance framework stays in the background and keeps people from getting themselves (and the company) into catastrophic trouble, the kind of trouble that is no longer useful as a learning experience for the individuals and the organization. At its worst, a governance framework ensures that no change or innovation is possible, by involving too many people and well-intentioned yet hard-to-meet policies in decisions.

Start-up companies rarely implement an explicit governance framework, unless they are active in a highly regulative industry. Relationships and culture make sure that work is invested in the right areas and compliance risks stay manageable - in a small organization, everyone knows each other on a personal level, and (hopefully) identifies with the company's mission. Very little auditable proof of governance is needed until the stakes get high enough that external investors or regulatory bodies start to care.

Obviously, innovations can reach the market faster if they don't have to go pass many extensive internal checks, and agile development frameworks are optimized for that exact purpose, to get innovations to market as quickly as possible. It follows that agile development frameworks are usually not strong on governance, and emphasize autonomy (= not having to ask for permission) at the level of individual contributors and teams.

So what does a large company do if it wants to accelerate innovation? It it's willing to relax its governance standards, it may spin out a development team as a separate company in a corporate incubator and tell the team to move as fast as possible. But what if the thing that's in need of faster innovation cycles is a mature product, or essentially the company's core business? Then the stakes are high enough that governance can't be sacrificed for speed, and the company needs an agile development framework that still offers control mechanisms on various levels. That's where SAFe comes in.

SAFe (the Scaled Agile Framework) is widely criticized for being prescriptive and complex. That's also the secret of its success - why it's not only frequently being introduced in larger companies, but those companies actually have some degree of success in using it: SAFe goes into great detail on what to do, and offers a home for nearly every administrative role (from PMO to Architecture and Controlling) that a more traditional organization already has in place. It also designed for managing dependencies (between system components, between technical teams, between business and technology). That makes it a great fit for organizations that work on large, complex systems. Introducing SAFe neither requires expensive technical rearchitecting to break a large system (and the business functions that depend on it) into smaller parts, nor does it require radical cultural and organizational change. Unfortunately, once SAFe has been introduced, there's also not much incentive to do any of these technical and organizational splits that would be the prerequisite for moving faster and reducing alignment effort.

As SAFe is mainly used for complex systems with many interdependencies, a high amount of alignment and governance is needed to keep small problems from derailing the whole release train. Let's take a more detailed look at the built-in mechanisms for accident prevention in the "agile release train" in SAFe.

Strategy and resourcing

SAFe agile principle #9 is to "Decentralize decision-making". Contrary to that principle, strategic decisions tend to be centralized and be made by people who are not necessarily closest to customers and the product. The Lean Portfolio Management function (LPM) is in charge of funding decisions, and also needs to approve significant development epics, in addition to supporting budgeting and forecasting in the overall concept of "Lean Governance".

SAFe repeatedly points out how agile development is different to "phase-gate" models. Here, success is all too often measured in terms of documents delivered. But still, SAFe can't get break free of the phase gates either - at the level of portfolios (multiple agile release trains / solution trains), SAFe still relies on phase-gate milestones and document-driven measures of completion - these instruments are just used more frequently than in a traditional model, namely at the end of each PI. Understandably, investors want to have visibility and control over the end result they are funding. But the question remains how fine-grained this control has to be.

Synchronized planning and execution cycles

The concept of "alignment" can be found very frequently in SAFe - as matter of fact, it is one of the core values of SAFe. With multiple teams working on the same interconnected system as part of an ART (and one "system" team to support development processes), the chosen way to reduce complexity is to essentially have everyone work in lockstep. All teams are synchronized and work based on the same schedule, from PI planning to demo, and deliver releases as part of the same PI.

This type of synchronized planning schedule also extends above the level of individual teams and ARTs; portfolio strategy and solution vision occurs essentially in a top-down way, with decisions rippling down into the teams, aligned with the PI schedules.

This approach is probably necessary to manage dependencies between teams and to include all the different roles a traditional organization has. However, does it give the organization incentives to reduce dependencies and promote more autonomy and bottom-up accountability? There is certainly a risk of unfinished work piling up in the PI cycles, as teams struggle to align and ultimately ship valuable features to customers - and the more unfinished work, the more wasted opportunities to generate value and elicit customer feedback.

Frozen decisions

To minimize friction when working in an enterprise environment, SAFe explicitly makes exceptions to its principle of "assuming variability and preserving options": When working with hardware solutions or external providers, technical decisions can be frozen in place ("fixed solution intent") in order to keep documentation up-to-date and minimize rework.

Governance roles

With alignment as a SAFe core value, it's hardly surprising that many cross-cutting or administrative roles can be found in the framework. Most notable among those are the "servant leaders" in a central oversight roles, the Release Train Engineer (RTE) and even more so the Solution Train Engineer (STE). The traditional PMO function is relabeled as "Agile PMO" (APMO), working on the top-down translation steps from strategy to themes and portfolio, and performing functions similar to traditional PMO, albeit in smaller increments and more frequently.

Shared service centers, such as expert teams for security, architecture and database administration, usually don't play an explicit role in agile development methodologies. However, their influence on software delivery shouldn't be underestimated - in addition to providing services, they often act as gatekeeper for cross-functional aspects, using their own policies for blocking or heavily influencing technical decisions in other teams. Therefore, they play an important role in maintaining the quality of technical deliverables, and SAFe rightly acknowledges their role. The shared service centers' influence even expands across ARTs, with system architects in charge of maintaining platform integrity through "subsystem governance" in scenarios with feature-area ARTs.

While the specialist nature of these teams is certainly good for cost-efficiency and depth of expertise, there is a risk of these service centers obstructing innovative approaches and holding incubating projects to higher standards than necessary. Also, specialist teams that own crosscutting aspects can cause problems with accountability: for instance, if development teams try to delegate quality control to a QA team or security to a security team, but those teams see themselves not as responsible but in a "consulted" or "supportive" role, it's unclear who is ultimately responsible.

Which path to choose?

We've seen that textbook SAFe offers a multitude of governance mechanisms. We've also seen some similarity between what SAFe offers and more traditional governance approaches, making it easy to implement SAFe without radically reshaping an existing organization. Arguably, the governance mechanisms used are "best practice" for achieving governance goals - if a company practices "textbook" SAFe. Still, the question remains whether alternative governance approaches could be more efficient in empowering teams without endangering the whole organization.

There are surely more radical approaches to agility than SAFe, which provide more freedom and accountability to the front-line teams. Those approaches tend to work better in smaller organizations. To reduce the need for expensive alignment and slow decision-making, business leaders could consider reducing dependencies between teams and their components, and finding subdivisions between parts of the business that could be split apart and could then operate more autonomously. Also, companies need to decide whether it's more important to cultivate narrow specialty areas (and have those specialists support multiple teams through shared service centers) or to place an emphasis on teams of generalists who can own their results end-to-end. Which path to choose depends on the relative maturity of the company and its products, as well as budget constraints.

‍