Why Scaling with SAFe is an effective way to realize the full potential of Agile
Before We Start – A Quick Preamble
This article will explore key facets of scaling Agile and the pantheon of competing frameworks. My intent is to stimulate thinking on this potentially complex subject, and perhaps provoke further dialogue on this emotive topic.
What is Agile Scaling?
Early attempts at Agile adoption were typically focused on implementations at the team level. Often, these initiatives were limited to localized Agile adoption within isolated pockets of IT organizations. These early efforts garnered some success, however, their impact was often stymied by traditional upstream linear processes (business/portfolio levels) and downstream tollgates (release management/siloed testing) that still injected delay in the flow of value to the end-user/customer.
More recently, the requirement to synchronize multiple development teams that need to collaborate closely on product delivery has forced organizations to consider how to better align their teams. Also, there has been a growing realization that business, operations, and engineering functions need to adopt a more seamless approach to working in concert.
So, put simply, scaling involves a movement toward Enterprise Agility that potentially expands upon proven patterns of Lean Agile behaviors and directs them to other groups and disciplines within the organization, which in turn, improves Business Agility.
Many Paths to the Top
Given the diversity of our broad Agile community, we certainly do not lack opinions on how to master the challenge of scaling Agile. As a result, there are a plethora of Frameworks and models with their own nuanced approaches and distinct nomenclature. The current range of popular approaches include LeSS (Large Scale Scrum), Spotify model, Scrum at Scale (S@S), Nexus, and SAFe.
Regardless of which model we use as the vehicle for change, these methodologies all share a common emphasis on:
- Providing a common frame of reference and language that transforming organizations can coalesce around
- Establishing a firm organizational foundation based upon the pre-existing, relatively mature teams
- Aligning and synchronizing those teams
- Establishing guard-rails around common practices and roles (while preserving the option to innovate and tailor to local conditions)
Whatever your choice of Framework, rather than fixate on a literal implementation, the key is to maintain a flexible approach to interpreting the concepts and derive solutions that fit and work on a local basis. As George Box (the famous statistician) once said- “All models are wrong, but some are useful.”
While there are many flavors of frameworks that provide guidance on navigating scaling, this article will focus on the way toward utilizing the most popular - the Scaled Agile Framework (SAFe).
Which Mountain Should We Climb First?
Often when considering Agile adoption, organizations jump straight to solutioning before they have fully articulated the problem to be solved. So, rather sensibly, SAFe recommends an initial focus on both defining the need and understanding the implications of adopting SAFe. This entails first educating the decision makers, and then performing an examination of the compelling reasons why such a transformation is needed (i.e. the tipping point). By synthesizing the organization’s strategy into a SAFe Transformation vision, leadership can make more informed decisions around setting the pace of change and defining sensible Agile adoption goals. There needs to be a clear tie-in to existing organizational, technical, or business goals. Leadership then needs to clearly communicate the rationale and intent behind the initiative to internal constituencies and external partners.
Once the rationale is in place, the next step entails identifying and defining the scope of the effort. Defining the organizational and product/project/service boundaries are key to ensuring clarity and expectations. For example, is this going to be an attempt to institute wholesale? Are we limiting the adoption to an incremental phased roll-out to minimize disruption? Or, is this simply going to be an experiment/pilot/proof of concept?
That’s it for now. But in part two, we will discuss proven patterns for successfully implementing SAFe.
