The concern of how to scale Agile comes up frequently when talking to our customers. Our inital response usually is: Don’t—if you don’t have to! The first step before scaling Agile should be to minimize dependencies whenever you can. However, the need for scaling still arises frequently: if more than one team works on one product or if several teams cannot avoid dependencies, we will have to face that challenge.
In this blog we’ll point out the aspects you should consider when scaling Agile and distill our experiences with some common frameworks we helped to implement with our customers. You will learn about different dimensions of scaling Agile.
As we work mostly in a Scrum context within our projects, we will focus on issues related to this framework and we want to provide guidance vis-à-vis a multitude of options available for scaling. We will point out those aspects we deem important to consider when evaluating options such as LeSS, SaFE, or Nexus.
First Rule: Avoid Scaling Agile if You Can
Before considering scaling Agile you should aim to minimize dependencies. Scaling up always comes at a cost: Any time teams have to manage dependencies, this adds an overhead in communication and coordination. Therefore, minimizing dependencies should be the guiding principle in tailoring the scope and structure of any team setup.
Consider scaling down or out before considering scaling up: Scaling down means that a small, effective team might deliver more than large teams that require more coordination. Scaling out describes the effort of providing more independence to your teams and reducing the necessity for coordination.
One issue that always occurs when scaling up, is that you also automatically scale up your existing problems. Therefore, you should only scale up on a sound basis, i.e. having a solid agile mindset established within your teams and Scrum should be working without major frictions within your organization.
Scaling Agile: Good or Bad? Consider the Driver for Scaling Agility!
By and large, there are three scenarios in which companies are driven to scale Agile: efforts can be driven from a project perspective, from the organizational or from a value stream view. For each case you should consider some basic caveats.
Scenario 1: Some projects are organized in an agile manner and the size of the projects is to be expanded.
One major advantage of Agile is based on the experience that small teams are usually more effective than large ones. Fast development and feedback cycles ensure that business value is produced early on.
After starting with an Agile team it is often tempting to expand the scope of the project and the number of the teams involved. Rather than going along this route, however, our experience tells that—as mentioned above—it is favourable to split projects into smaller entities that can create value independently.
Scenario 2: Agile is practiced in a few teams and is desired to be spread across the organization.
Most of our customers get started on the path towards agility by selecting a pilot project for Scrum in order to gain experience with an Agile framework. This is an excellent way to get familiar with the characteristics of Agile practice and can set the basis for raising efficiency in a development team.
However, we often encounter the expectation that Scrum can also help the organization to be more effective. This is a dangerous assumption, as the purpose of Scrum is to provide a team level framework, which excludes several factors that are essential for coordination on the project management- and organizational level. Hence, some thought needs to be dedicated on how to integrate Scrum into the existing organization, align it with current processes and create the necessary acceptance from people within the organization. For this, there is no „one size fits all“ blueprint of implementation: it has to be tailored to the the existing organization.
Scenario 3: Agile teams cover a small portion of the product value stream. The goal is to expand the agile mode to the entire value chain.
Our experience shows that a value chain oriented approach entails the most constructive route to scaling Agile. This ensures a customer-centric perspective, which is in line with agile philosophy. Creating business value constitutes the very foundation and core principle of working agile. A challenge usually consists of finding a common understanding of business value across the organization. Value can be created by raising customer value, but can also be generated by e.g. lowering operations costs, reducing risk, etc. In any case the business value-centered view can provide priorities and orientation across teams.
Therefore, when scaling Agile, all parties that contribute to the value chain should be involved. This is not confined to IT aspects, i.e. finding a suitable setup for integration of UX and operations into the development process; more broadly, also product management and business stakeholders should be involved. If shared services such as operations are involved, these usually represent a bottleneck and the limited resources themselves need to be prioritized according to business value so they can always support in gaining the most business value first.
No matter what the driving force is for expanding agile methods, you should always include three factors in the planning of scaling: Culture, complexity and individuality of the organization.
The Three Factors of Scaling Agile
Culture
Moving an organization towards Agile always requires cultural change. This factor tends to be underestimated. Hence, a strategy for cultural change should always accompany the endeavor of scaling Agile. Agile culture includes welcoming transparency, collaboration, and customer orientation. This change process will take time. It cannot be prescribed by management, but change initiatives are usually doomed if they lack management support.
Complexity
Agile transformation represents a complex challenge. We recommend implementing an agile change process along with the introduction and expansion of agile projects in the company. An iterative mode for the change process—with short-clocked inspect-and-adapt-cycles—ensures staying on a constructive path.
In regard to collaboration one of the main challenges is that in a scaled Agile environment, a single team cannot produce business value on its own. Therefore, it is even more important that a common goal exists across teams to produce value, backed by a clear and shared vision. To ensure the delivery of value, an iterative and incremental approach on the scaled level represents an enormous benefit in terms of cross-team alignment.
Individuality
Every organization is unique. In every enterprise there are individual organizational features, processes, and cultural peculiarities. Furthermore, there are special needs regarding its workforce and customers, and differentiations regarding products and their production. Therefore, there will never be an off-the-shelf blueprint for Agile transformation. Several commonly used frameworks can be considered scaling Agile, but you will always have to take a close look at how to tailor existing frameworks to your organization in order to provide a perfect fit.
Guiding Principles for Scaling
After taking a look at the motivation for scaling Agile and the organizational status quo with our customers, we usually come back to the question of which framework to chose. It saves a lot of painful learning experiences to use a thoroughly tested framework as the basis for your endeavor, rather than trying to re-invent the wheel.
From our experience, we can usually recommend a specific model as a starting base, taking into account the given situation. But, as mentioned before, every company is unique and there will always be some adjustments necessary to provide a good fit for the organization.
For any change, you should make sure that the all dimensions of change have been considered, in particular company culture, the role of leadership, and the existing organziational structures and processes.
For an iterative approach we prefer to keep things as simple as possible – the LeSS and Nexus frameworks offer some major benefits in regard to their fairly lightweight approach.
Both the SaFE framework and the Spotify model are frequently employed when taking a „Big-Bang“-approach to change, overhauling major parts of the organization. One of the major pitfalls we encountered in many projects taking this road is that they are „too easy“ to implement without taking the conscious decision to make some bold changes in work, hence not triggering the necessary cultural change towards Agility that is required for a successful transition.
When drawing on any framework, one should keep in mind that they never should be taken as a blueprint unquestioned. When advancing Agile in your organization you should first focus on general Agile principles, i.e. focus on the product, customer orientation, and regular feedback loops. On this basis, we can consider the different frameworks as a toolbox that can provide the fitting instruments for your individual challenge.
If you like to learn more about how inovex can support you in your journey towards Agility, you can find more information on our website.
