Being capable to react to change with agility is a key requirement for all companies onboarding digital business models or digital products and processes. And when it comes to competing and staying relevant, agility is becoming a necessity. Large companies, however, appear to face a plethora of challenges with balancing agility and stability. Indeed, implementing Agile outside the technical domain often fails.
A big cause of failure for large organizations is the attempt to apply one of the many off-the-shelf Agile models. These typically work well for small companies, but not so much in large corporate settings. This two-part Advisor offers a four-part framework to scale and customize a tailored Agile approach that caters to an organization’s specific requirements. Here in Part I, we explore the first half of the framework beginning with assessing your needs in the understand phase. We then describe how picking building blocks from the many Agile concepts available will shape a working model according to the needs of your enterprise.
The Challenges of Agility
Companies are continuously looking for ways to adjust not solely their business models, but also their organizational setups. Agility and flexibility of processes, structures, ways of working, and culture are becoming the new paradigm. Large firms, in particular, need to balance becoming more agile and flexible with retaining stability in certain core processes to ensure productivity at scale.
Many large organizations are not suitable for rapidly changing environments because they struggle with the ability for fast-paced product and service development against internal projects and business processes. While Agile is familiar to many executives, it is often solely associated with IT; often, the wider organization misses the opportunities Agile offers for transformation. Additionally, many companies attempting to implement Agile outside the IT domain fail due to lack of understanding, insufficient readiness, or poor implementation. They struggle to combine Agile and traditional principles in a way that delivers the benefits of both and therefore fail.
A Framework for the Right Amount of Agility
We use a simple framework that makes it possible to address these challenges and determine how much agility a certain area of the organization needs. We can apply Agile elements for various business situations and topics in a way that retains empowerment and simplicity yet avoids upfront overspecification. Agile can span single teams, smaller processes, customer needs/business services, projects with large budgets, entire product lines, or even the complete reshaping of large business units. This framework comprises four main action points: understand, shape, learn, and adapt (see Figure 1).
Understand Your Agile DNA
Understanding the current situation of the company, department, or project is crucial to identifying barriers and deciding the most suitable level of agility. We need two perspectives before we can shape the new model: (1) What is the need for agility in a specific area, whether it is product, project, or process; and (2) What are the capabilities and skills of the organization?
Regarding need for agility — “agile urge” — try to understand the ideal amount of agility for your organization’s given area:
What is the customer or end-user need? How well is it defined, and how likely will it change? The more unpredictable or variable the need, the more agility can help in staying at the head of the race.
How “digital” is the environment? For example, digital products and services for customers are intuitively more suitable for higher degrees of agility.
What is the business criticality of the current situation? What will be the consequences of applying an Agile model and failing, versus doing nothing? Could Agile help improve the competitive position or tackle new segments?
At the end of this step, stakeholders can more easily align themselves on common objectives for introducing agility.
The second perspective — an “agile pulse check” — provides an understanding of current capabilities and skills. It assesses how ready the organization is for the changes ahead. Factors to focus on include:
The scope of the change. Is it a discrete environment, or is it highly intermingled with the rest of the organization? For example: a new customer experience in an online shop can have anything from a negligible to a relatively huge impact on the processes and organization in wider parts of the company. Agility in developing something new on the front end can conflict with the need for stability and security on the “hidden” back end (e.g., order-processing solutions and processes). The Agile approach therefore needs to account for this, and stakeholders need to assess the potential impact on other parts of the organization.
The number of people involved. What experience do your employees have in Agile working environments?
Product/service characteristics. How easily can your company realistically introduce agility in its current setup?
Key Aspects to Understand
Understand the degree of change in customer demands and expectations around products and services.
Understand the volatility of the market and disrupting trends. Which trends are challenging established business models?
Understand the experience and capabilities of your organization, staff, and management in working with Agile methodologies and adapting to the new working culture. (Don’t underestimate possible open and hidden opposition against Agile change for many reasons, such as loss of power.)
Understand the different objectives and align them toward a common goal.
Shape Your Agile Working Mode
In small companies and IT/project environments, Agile methodologies like Scrum have already proven their worth when it comes to increased project delivery speed/quality and decreased time to market, while simultaneously reducing costs. Evolving Agile methodologies can help bring projects to more suitable larger scales (e.g., Large-Scale Scrum [LeSS], Scaled Agile Framework [SAFe]), but there’s no one-size-fits-all solution. Again, we need to address the outcomes of the understand phase and adapt and combine different frameworks to best fit customer requirements and internal capabilities. Single frameworks can sometimes be used, but it is often better to combine a number of “building blocks” extracted from these frameworks to shape a customized and better-fitting solution.
On top of the pure Agile and product-/project-oriented methodologies, the toolbox can be augmented with building blocks from Agile-inspired management methods (e.g., Holacracy for organization or Objectives and Key Results for goal setting and steering. To be successful, these methodologies must be applied through a comprehensive approach, covering processes from idea to launch. This requires a targeted application and combination of Agile elements and artifacts to achieve the benefits that Agile methodologies promise. Key for success is to keep the DNA of the main methodologies or working models intact; otherwise, the great ideas and concepts deflagrate and leave only buzzwords, or even chaos, behind. Additionally, the interface toward the remaining “non-Agile” part of the organization must be clearly defined and shaped to ensure the coexistence and seamless integration of both concepts. Based on findings of the understand phase, an organization can then select the right Agile building blocks to create a customized setup that integrates flexibility within the existing corporate structure.
Key Aspects to Shape
- Shape a tailored approach for your company through combining different methodologies based on the internal abilities and external market and customer circumstances.
- Shape according to the needs of your business domain.
- Shape so that the parts of the organization that require agility and stability can efficiently work together.
- Shape in a way that defines synchronization points clearly.
In Part II of this Advisor series, we will continue our examination of this framework with a focus on the last two parts: learn and adapt. We will also highlight examples of large corporations overcoming obstacles.
[The authors would like to acknowledge the input of Richard Beetz in preparing this article.]