Agile transformation of the (IT) Operating Model

Introduction

Digitalization forces organizations to place flexibility and time-to-market at the core of their business model. Companies like Spotify have been doing this from the start, with the ability to quickly introduce new products and services tailored to changing consumer needs. These companies are shining examples for the more traditional players, who are struggling to respond. In order to keep up, many organizations are experimenting with agile in their (IT) Operating Model. This goes beyond applying agile IT development methods such as Scrum, but instead moves towards adopting agile principles throughout the entire organization. Embracing agile at an Enterprise level is widely believed to lead to the much-desired increase in flexibility, time-to-market and customer satisfaction ([Cull17]).

However, organizations that decided to radically change their (IT) Operating Model have proven that agile cannot be regarded as a silver bullet. The traditional world is often faced with rigid organizational structures and legacy, making it difficult to successfully implement agile at scale (see for example [Bish15]). Different frameworks are adopted (e.g. SAFe, Spotify) in various ways and at different levels in the organization, often leading to suboptimal agile transformations. What can we learn from these transformations in practice, and what are considered to be common pitfalls when trying to incorporate agility at an enterprise level?

This article shares the agile transformation stories, observations and lessons learned as experienced by KPMG at clients across a variety of industries (Telcos, Corporates, Financial Services, Public Sector). We will outline how agile is changing the (IT) Operating Model by sharing our observations related to each element within the model. We will also share our main insights regarding agile transformation pitfalls and lessons learned. These insights are a reflection of our own experiences, as well as gathered insights based on interviews with business and (IT) management.

Introducing agility in the (IT) Operating Model

Figure 1. The (IT) Operating Model incorporates all structural elements necessary to maximize the business strategy, including the added value of IT within business value streams. [Click on the image for a larger image]

A shorter time-to-market of new ideas demands a change of the (IT) Operating Model, increasing speed and flexibility. This requires new ways of collaboration between the business and IT. In the old model, the IT function is purely supportive of the business with a traditional demand-supply set-up. As we move further into the digital age, the divide between IT strategy and business strategy is fading. The introduction of agile at scale means intertwining business and IT. This implies a fundamental change of the entire operating model.

Organization & Governance

To enable a higher involvement of the business in IT development, it is essential to have the right governance and organizational structures in place. A change in roles, responsibilities and collaborations between functions also means a different focus on decision making. In an agile environment, this becomes increasingly decentralized, empowering selected domains.

Observations:

• Organizing Business and IT in value streams under the business removes impediments and constraints in handovers across silos and leads to a greater sense of shared responsibility for solutions;
• Differing needs of business functions often result in the rise of a hybrid IT organization, frequently called ‘bi-modal’ or multi-speed ([GART16]). When increasing agility and changing the operating model, anticipate the need to govern multiple speeds and consider ways to synchronize the length of the teams’ development cycle;
• Be aware of governance and function changes only adopted in name. We frequently see the change of existing functions to new names (e.g. the project manager becomes a ‘scrum master’). This leaves existing hierarchies and working practices in place resulting only in incremental improvements on the old instead of defining the new;
• We frequently see the introduction of multidisciplinary teams in IT, but only limited business involvement or a product owner from IT. When these teams are not involved enough or managed by the business, the agile transformation will not reach its goal as existing old demand-supply constructs stay in place.
• Agile requires careful board involvement. Self-steering teams require empowerment, trust and sponsorship from higher management. This sometimes conflicts with senior management need for traditional control mechanisms.

Capabilities, Services & Processes

To successfully increase the agility of the organization, new capabilities are required, and services and processes need to change. The organization must learn to focus on value through end-to-end value chains, instead of optimizing a specific activity as part of the optimization of silos. Building on Customer Journeys as a leading concept helps to drive this change and identify which products teams should focus on.

From a technology perspective (described later in this article) the organization requires a strong architecture function, driving modularity and enabling continuous delivery through automation of IT for IT. Additionally, new capabilities should be built based on agile tools and working methods. Examples are stand-ups, Kanban, visualizations, definitions of done, epics and user story definition. Many of these capabilities can be drawn from scrum and lean, but the most challenging aspect is to start scaling these practices. When scaling across more than just a few teams, organizations must adopt means to manage integrated backlogs and align teams. Frameworks such as LeSS and SAFe provide examples on how to organize these capabilities (e.g. PI meetings, integrated backlogs across areas, etc.).

A lean approach is a good starting point at a process level. Learning to identify and remove impediments in processes to enable teams to work smoothly drives agility. These impediments are frequently encountered in traditional service management processes. Organizations should be willing to change traditional service management processes when agility increases.

Observations:

• When empowering teams and actively supporting the removal of constraints, the speed at which teams adopt new practices often surprises organizations. It turns out adoption is frequently much faster than expected. This requires organizations to think about scaling from the start;
• Service management processes are difficult to change. We see many organizations struggling with these processes. Organizations that successfully change service management, typically invest heavily in automation of IT for IT and introduce new tools to this end;
• When impacting service management processes, compliance and security are often involved too late. When starting the agile journey, organizations should involve their security and compliance functions to help redesign processes. We frequently see these functions being involved too late, leading to resistance rather than support;
• Projects are no longer the way of working. IT and business are integrated in one chain and therefore less complicated within teams;
• Start learning quickly through experimenting and pilots. Learning by doing and finding constraints by experience are the best ways to pave the way for agility;
• In the ideal world, no coordination mechanisms are required as teams self-organize and find each other in case of dependencies. However, coordination mechanisms are important when starting the transformation. We have learned that this is underestimated by most organizations. As teams grow in maturity, control mechanisms can gradually be reduced. In practice, managing functional dependencies between the agile teams is challenging and leads to additional functions, frequently resulting in the survival of the ‘project manager’ function;
• Agile is not the holy grail for everything. Specific changes such as asset heavy (e.g. infrastructure, construction, etc.) projects with fixed deadlines still require a project management approach.

People & Skills

The behavior of people will eventually determine a successful change to agile. Agile teams require people with intrinsic motivation and the ability to work in flexible teams across the boundaries of traditional departments. Profiles that value both specialization and looking across disciplines (T-shaped profiles) are highly valued in these environments. It is important to acknowledge that working agile is not for everyone. Only teams with the proper mindset who are supportive of the new working model can make an agile transformation successful.

Observations:

• Agile can only thrive in an environment which promotes transparency and involvement. People need to have room for their own initiatives without being punished for mistakes;
• Acknowledging and managing the difference between (technical) knowledge and competences (like collaboration skills) is important to enable successful teams;
• New employees who were not part of the regular way of working of the organization can accelerate the agile transformation as they are often more adaptive towards new working models;
• We see many organizations introducing agile coaches. We stress the importance to recognize the need for agile coaching on three levels: (1) coaching board level on leadership in an agile environment, which is something completely different from (2) operational and project management, and (3) team level application of scrum practices;
• Although agile coaches must be independent from the teams and are frequently external, having champions in your organization promoting agile prove to be a great accelerator of the transformation.

Performance Management

Performance and the way we measure it has changed in the agile environment. Performance evaluation is team-based or organization-wide, instead of individual.

The measurement framework contains metrics that are data driven and real-time, and focus on value of epics and capacity instead of activities. Progress velocity becomes a key metric to show team performance and predict the extent to which epics and user stories are completed.

Budgeting is in line with agility principles and focuses on capacity, rather than trying to completely specify the outcome and assign budget accordingly. The business manages the IT budget and determines priorities within IT. In the end, this drives higher cost transparency on IT spending.

Observations:

• Involving board level management in how progress and budget exploitation remain clear and even become easier and better to govern, is essential and crucial for accepting the new way of working;
• We frequently see organizations starting to change the performance metrics for their employees too late, resulting in discrepancies between team goals and individual performance. HR should be involved in any agile transformation from the start;
• Organizations are experiencing difficulties to manage metrics like team velocity, instead of knowing in detail when things are finished. This requires proper understanding of concepts and effective coaching on the three aforementioned levels in the organization;
• To actively support the change, it should remain clear who is responsible for the budget;
• Planning and control cycles within the overall organization frequently do not fit the new structure. We see discrepancies between long cycles versus short iterative approaches.

Technology

The technology domain is essential to successfully drive and support an agile way of working; to enable teams to work in short cycles and frequently deliver value.

Observations:

• Automation and digitalization of the environment should (already be) a key attention area. We see that organizations that have successfully transformed their operating model can usually build on an environment that has been the subject of rationalization and digitalization in recent years;
• The features and components they are working on should be small, requiring architecture to be modular and easily interconnected (e.g. micro-services, APIs). Although conceptually easy to grasp, this is very difficult to attain as it frequently requires rationalizing applications and replacing legacy, including middleware;
• IT service management processes should be responsive and quick. Among other things, this requires the strong automation of IT for IT, and a vast focus on tools for aspects such as testing, continuous integration and continuous deployment.

Although not every business function requires the same extent of maturity in the aforementioned items, the relation between organization agility and the technological capability (continuous delivery) is shown in Figure 2.

Figure 2. Agility requires balance between technology and organization. [Click on the image for a larger image]

Observations:

• The need to digitalize the organization and modularize architecture is frequently overlooked. Organizations quickly build agile capabilities in their teams, but are subsequently bound to quarterly release cycles and manual activities proving constraints on their speed;
• From an architecture point of view there is no one-size-fits all model. Depending on the length of the development cycle that the team works in, and the speed at which the release of value is required in the business, architecture should be adopted accordingly. Although frequently positioned as the holy grail, we do not regard an architecture completely based on micro-services to be the most suited end-goal for all organizations;
• We observe a strong focus on test automation, which is usually regarded as a no-regret move. However, testing is only one element of continuous delivery, and sufficient focus should also go to continuous build, integration and deployment;
• Adoption of the cloud, especially on an infrastructure level, provides the required flexibility. However, we see organizations moving to the cloud without clear business cases, or acting on the assumption that the cloud is always the economically most sensible route. Although cloud is a strong driver for agility, we urge organizations to build a sound strategy on the cloud, not only driven by economic factors.

Sourcing

A transformation to agile also implies an assessment of your supplier relations and capabilities: how can they help to stimulate your agile transformation, or where are constraints that need to be dealt with? Likewise, the internal skills to collaborate effectively in agile partnerships need to be assessed, and the manner in which the supplier is part of integrated chains should be designed and implemented.

Observations:

• It is important to look at current supplier contracts for constraints and impediments to your agile journey. We see that organizations are usually afraid of opening up contracts and changing the manner in which the cooperation is shaped. However, organizations that do engage on this journey proactively prevent complexity at a later stage, and typically state that this change is key to their agile transformation;
• We see the rise of multisourcing models with increasingly fluid relations between the business and suppliers. Although this allows for flexibility in adding and removing suppliers from the ecosystem, it is frequently challenging for IT to guarantee quality and continuity, and difficult to manage the supplier base. Sufficient attention on how to organize supplier management in an agile environment is important to prevent ‘supplier spaghetti’;
• Not only technology partners need to be assessed, partners are also required to strengthen agile organizational skills;
• For example, we see organizations leaving their culture and leadership programs unchanged, while engaging agile coaches, and implementing training programs such as SAFe, and business scrum. This easily leads to discrepancies.

High quality agile coaching, based on consistent approaches, is the key to success. Agile coaches should be independent from operations, and therefore acquiring external agile coaching is a logical choice we continuously see in the market.

Lessons learned

1. Clearly set your ambition and create a compelling vision

In line with market views, KPMG recognizes various levels of agile maturity and ambition. This ranges from agile at IT to scaling towards business functions and agile at the enterprise level. Not every organization will be completely digital, requiring agility at the enterprise level. We urge organizations to set a clear agile ambition at the start of their journey and clearly articulate their vision and mission based on an understanding of their current position.

Figure 3. Agile maturity and ambition levels. [Click on the image for a larger image]

2. Choose a fitting transformation approach

Unfortunately, there is not one approach guaranteeing a successful agile transformation. The right approach is (among others) dependent on the organizational context, maturity level and ambition of the agile transformation.

The approach is based on clear choices, that jointly determine the agile transformation journey. For instance, a big bang approach is the best option in case of a relatively high urgency, or when an elaborate cultural shift is desired and top management is completely on board. When only certain business domains are within the scope of the transformation and when aiming for a gradual increase, an incremental approach is better suited.

Figure 4. Agile transformation choices. [Click on the image for a larger image]

Where bottom-up approaches are often a catalyst for change, driven by (peer to peer) agile enthusiasm, DevOps and continuous delivery, a focus on a top-down approach becomes essential when introducing agile at scale.

3. Experiment and learn by doing

Any agile journey starts with experiments and pilots. Following agile principles, the best way to learn a new capability is through experience and failing fast.

Learning by doing makes this model work. It’s not just another way of working, but also another way of delivering results. Starting in one part of the business by experimenting can be helpful to understand the new way of working, but this should all be based on a clear enterprise wide defined vision.

By having pilots in the organization and experimenting with the challenges in each domain of the operating model, the constraints become visible. These are key input and determinants for the agile journey.

Figure 5. KPMG view on a typical agile journey – start with experimenting. [Click on the image for a larger image]

4. Commitment of Senior Management

A transition to agile can be driven by the strength and enthusiasm of employees in teams and their management. However, when the transition starts to require scaling into larger initiatives (projects or programs) or into business functions, support from senior management is required. This is not only valid for IT (where initiatives frequently start), but especially within the business. The business needs to increase responsibility for IT, budget and priorities. Also, the required change in culture, performance management and governance structures can only be driven by strong business leadership.

Self-steering teams require empowerment, trust and sponsorship from higher management. Promote the autonomy of co-workers and let them take responsibility for their work and delivered outcomes. Nevertheless, there must be a clear and concrete agreement on targets, results and new methods to stay in control.

Lack of management commitment to change to a new working environment will lead to half implemented solutions and processes resulting in frustrated co-workers. In our experience, agile transformation really starts to gain traction at the moment senior business stakeholders start to embrace the concepts and drive the transformation across the boundaries of IT.

5. Place sufficient attention on architecture

The journey to agile can provides a challenge for the architecture function. From a function perspective, architects used to be part of larger change initiatives and build upon bigger designs. The transition to agile requires architects to divide their attention among many different teams with potentially differing missions. As such, architects will need to connect with or be organized close to those teams.

From a principle perspective, architecture remains crucial to prevent agility, leading the organization into complexity and chaos. Standards are required to provide boundaries and ensure consistency in the overall technology landscape. As such we have seen the architecture function becoming more important, reporting directly to the board to govern teams in an agile environment.

Working in self-steering, autonomous and multidisciplinary teams within boundaries set by Enterprise Architecture requires communication and determination of group-wide policies and standards on architecture, focusing on:

• Development of standards and procedures to drive architectural integrity and simplicity. Ignoring technical debt may be helping the business to launch the necessary applications in the short term, but will in the long run lead to additional costs for maintenance and support, eventually reducing flexibility.
• Drive modularity and far stretched automation of IT for IT, to enable autonomous teams.
• Stimulation of interoperability, connectivity and sharing of resources. A strategy and centrally governed platform for code revision control exists to allow scaling across functions and combine development capabilities.

6. Take responsibility and clearly define roles

Ensuring enough autonomy for co-workers is key. Besides giving them their own responsibility, it is necessary for them to take ownership.

An unclear definition of roles and responsibilities usually ends in frustration and uncertainties. The poorly defined role of the Product Owner is exemplary for this.

Successful adoption of agility frequently goes hand in hand with a strong simplification of functions to provide clarity. We have seen implementations where the number of IT roles alone was reduced from over 60 to under 10.

7. Change competences and behavior

Changing existing processes and standard procedures is difficult. Working in an agile organization requires T-shaped profiles, where co-workers are obligated to work outside their job description. Teams formed around a common goal might motivate people to step outside their usual boundaries. Transition to an agile environment requires other profiles than the existing ones. Holding on to old habits will lead to suboptimal results, e.g. ‘scrumfall’, instead of agile working.

Figure 6. Processes and behavior in the classical or digital world. [Click on the image for a larger image]

8. Choose a framework, any framework or a combination of frameworks. In any case, make a clear choice and remain consistent

The transition to agile requires a renewed look at the operating model of which various aspects were discussed in this article. Various frameworks exist that can help in understanding how to organize for agility and scaling, and which roles and functions to create. In practice we see that various frameworks are in use, and organizations frequently combine elements of methods and frameworks that best suit their organization. Make a clear choice among frameworks and how they relate, in order to prevent overlap. Also, avoid flooding the organization with new terms and ensure consistency of agile terminology and concepts during the transformation.

Figure 7. Agile and lean frameworks and methods – inspired by ‘Agile PMG’ by Miroslaw Dabrowski, 2015. Expanded based on KPMG insights and market analysis ([Dabr15]). [Click on the image for a larger image]

Conclusion

A transition to agile helps organizations to stay relevant in our increasingly digital world. Current structures and the traditional role of IT simply do not meet changing business requirements, focusing on flexibility and time to market. However, realizing the benefits of agile and successfully transforming the (IT) Operating Model is not without its challenges.

The road to becoming agile is not clearly laid out, and implies a specific journey for every organization. Throughout this article, we have shared important attention areas of this journey by taking the (IT) Operating Model as a leading perspective. The impact of agile on all of the elements within the model provides structure to the agile transformation, and can help guide decision making. The sequencing and prioritization of activities remain dependent on specific contexts. When helping organizations with their agile journey, it is our aim to guide the most important transformation decisions, while always allowing enough space and flexibility to adapt and learn.

In any case, the urgency to change and impact on the structural elements mentioned in this article are high. Therefore, organizations are forced to act fast and change in the right direction. Making smart choices when transforming the (IT) Operating Model is essential to achieve and maintain business results. Changing to a new model cannot be realized overnight. Transformation usually starts small with experiments and pilots in the appropriate business functions. Successfully expanding the transformation should be the gradual result of a responsive, learning organization, willing to break with traditional structures and provide empowerment and trust to its employees.