Is SAFe Agile?
I don’t spend a bunch of time on LinkedIn, but the other day, I was scrolling around and happened to catch a thread where some folks in the Agile community were debating if SAFe was actually Agile. People have been debating this topic for as long as SAFe has been around. The post generated a lot of good conversation, so I thought I’d take a minute and share how I think about this.
In short, it really comes down to what you mean by Agile and Agility.
A few years ago, I was discussing the idea of scaled Agile with Alistair Cockburn. One of the original signatories of the Agile Manifesto. I’m going to paraphrase, but he said something to the effect that “what we did when we invented Agile was a specific thing. The emerging methodologies for Agile at scale are not that thing. It doesn’t mean they are bad. It’s just means that, by definition, they aren’t Agile.”
That comment really stuck with me and it shaped the way I tend to think about Agile and Agile at Scale and Agility.
What is Agile?
Agile is an incremental and iterative approach for developing software products. It’s typically best for small teams. Typically, of 6-8 people. Agile methodologies adhere to the values and principles articulated in the Agile Manifesto. The most common small team Agile methodologies are Scrum and XP, maybe Kanban, or a combination of the three.
Scrum focuses more on management activities. XP focuses more on technical practices and software craftsmanship. Kanban focuses more on flow and less on teams and time-boxes.
Agile teams, by definition, operate independently, in close proximity to an actual customer or product owner. They deliver frequently and get constant feedback. Requirements are written in such a way that it’s easy to change and reprioritize. Software is written so that it’s safe to go fast and so you know instantly if you’ve broken something along the way.
There are various methodological practices that enable an Agile approach. You have ceremonies and cadences, ways you track progress, techniques for safely writing, testing, and deploying software; and various roles and responsibilities that make up a typical Agile team.
You have cultural aspects in terms of how teams collaborate, respond to change, and engage with the marketplace. You have a mindset of ownership. A disposition toward empowerment. And an attitude of collaboration with each other and the marketplace.
当敏捷第一次出来，或者实际上它第一次开始获得主流知名度时，许多人正在学习框架并试图应用价值观和原则。他们正在大型组织中运用许多核心条件以支持敏捷生态系统的实践和思维方式。
他们没有小组。他们与客户没有紧密的距离。他们没有需求和系统架构可以更改。也就是说，敏捷方法是各种强迫函数。您使用它们，它们向您展示您的障碍。您消除了障碍，并且随着时间的流逝，团队会变得更好。
But many of the impediments in larger organizations are difficult to remove by a single team. Especially if that team works in a larger ecosystem of teams, building bigger, more complex products, with heavy corporate governance and financial controls. The net effect is that teams changed Agile, rather than letting Agile change the teams and the organization.
So, in practice, we have lots of teams and organizations that are going through the motions, doing all the Agile roles and ceremonies, but not achieving any of the real goals of Agility. Being able to collaborate with our customers and making sure they’re building products that they want to use and are willing to buy.
Where Does SAFe Come In?
Sometimes I’ll describe an Agile team as one where the entirety of the value stream can be encapsulated and delivered by an onsite customer and a dedicated team.
Team based methodologies tend to break down when the value stream cannot be encapsulated within a single team. In other words, when we have dependencies between the team and other parts of the organization.
SAFe is a response to larger, more complex value streams, where dependencies have to be orchestrated and we need to align with corporate priorities, funding models, governance and control.
安全得到您必须在工作的组织的基础上拥有Scrum团队。但是，当您在团队之间尚未解决的依赖关系，解决迟到并破坏可预测的交付节奏时，您必须对他们做些事情。您要么打破依赖关系，要么管理它们。您不能忽略它们，而且他们通常不会自我组织。
On some levels, SAFe is like Scrum. It assumes the practices will reveal the impediments, and teams will remove the impediments and improve over time. But what do you do when the impediments are outside the purview of the team?
因此，我对安全的看法是，在依赖关系和公司治理的存在下，以及有必要让很多团队一致与综合交付的可交付方式一起操作……您需要某种方法来管理它。您可能不喜欢安全实施的角色，责任，仪式和开销，但是如果您按大规模进行软件，则需要有一些东西。您只是做……这是一种不可思议的。
So, pick your poison. You break dependencies between teams, or you manage them.
What you can’t do is pretend like they don’t exist.
Is SAFe Agile?
Clearly not.
至少不是敏捷宣言的签署者打算的方式。
安全最好的可以基于小团队。毕业舞会ote incremental and iterative development. It can support rolling wave planning and progressive elaboration of requirements. It can allow a company to get better at delivering to market faster. Getting more rapid feedback. Maybe even generating revenue that will help sustain future development.
A well implemented SAFe organization can use solid software craftsmanship practices. Good architecture. Solid design principles. Whatever technical practices you so choose.
Most organizations don’t understand the fundamental organizational changes required to make SAFe work, so we have a lot of poorly implemented SAFe.
In all fairness, most companies adopting Agile don’t do small team Agile very well either. At least SAFe isn’t ignoring dependencies. It isn’t ignoring the corporate governance that hasn’t been dismantled yet either. It’s taking a stab at trying to deal with some things organizationally that most of the Agile community willfully ignore.
What are You Willing to Change?
I tend to be methodology agnostic. I don’t find this debate super useful.
Every Agile methodology ever invented, was used by some consultant, in some organization, in some engagement and was successful.
这些方法被整理成实践。认证被铸造。我们告诉每个人，这是按大规模进行敏捷或敏捷的方式。所有这些方法在某个时候都在某个地方工作，并且都具有非常常见的参考架构类型元素。这取决于关于企业本质的基本假设以及该企业的哪些方面您愿意解决以使事情变得更好。
You have to make changes in most organizations to do small team Agile well. You have to make changes in most organizations to do Scaled Agile well. The problem lies when we take the methodology and apply it in a context where it wasn’t designed to work. We don’t understand why the practices worked, or what changes are required, so we have large groups of people going through the motions and not getting the business benefit of the approach.
任何方法。
Nothing is Perfect
归根结底，您的敏捷方法将受到您愿意做出改变的限制。这将受到您愿意或有能力拆除和重建的限制。
这就是为什么Leadagile专注于方法论的原因。
无论组织的规模如何，大多数公司都在书中努力做Scrum或XP。鉴于其复杂性以及价值流的重叠和交互程度，大多数公司将难以实施安全。大多数公司对如何组织团队或组织什么都没有很好的感觉。
They don’t have the environment to do Agile well. They don’t have the environment to do SAFe very well. And none of the scaled methodologies really solve the problem. You have to have encapsulated teams, and encapsulated organizations, that lead to the ability to operate with some level of independence. Dependencies kill Agile at all levels of scale.
Why would we just train the teams on Scrum and SAFe and let them stub their toe over and over again?
My observation over the past 12 years of leading large-scale, global Transformations is that Transformation is a process. You do what you can do today, while you mindfully change the organization to improve its design and break dependencies, while moving closer to your desired end-state as the organization makes adjustments and improves.
在组织设计不良，技术架构，不合标准的发展实践和依赖项的情况下，您做出了一组选择。但是，随着您改善生态系统，您可以拆除其中的一些决定，减少开销，并以更大的敏捷性运行。
The patterns necessary to do Agile or scale Agile well are well-understood. They just don’t lend themselves to certification or training. They require deep understanding of organizations and organizational design and change management. There is no “easy button” for getting this right.
I think the rub comes when SAFe is promoted as THE WAY to do Agile at scale. SAFe is one way to get started with Agile, while you create the conditions to really make Agile work as designed. At best it’s a transition pattern that can increase Agility while you’re moving toward a dependency-freeAgile ecosystem. And as far as transition patterns go; it’s a solid transition pattern. It’s just not my preference as a desired end-state.
The ironic thing is that most companies need more planning and preparation up front when they’re getting started with a Transformation. More planning than SAFe prescribes. But the idea is to deprecate some of the planning and compensating controls as the organization breaks dependencies, gets better at delivery, and learns to trust this new way of working.
As the organization improves, you can lighten up the practices and get closer to the ideal where it makes sense.
That is why this isn’t about the methodology, it’s about orchestrating and leading change, to systematically and intentionally create the conditions you need to operate with ever increasing Agility. Until we realize and understand the underlying patterns. The work required to do the change. And the time and attention it’ll take to get there, I think these debates will continue.
Is SAFe Agile?
So, is SAFe agile?
At the end of the day who cares. It isn’t what the authors of the Manifesto intended, but they didn’t ever anticipate their small team methodologies being applied at the levels of scale we are trying to apply them.
Can SAFe lead to greater Agility?
当然……绝对可以。对于许多组织而言，安全就足够了。这只是大规模敏捷的唯一方法，它甚至可能不是大规模做敏捷的最佳方法。但是，在我们愿意认真对待破坏依赖性之前，这可能是一个合理的妥协。