Prior to embarking on a transformation journey, executives and transformation leaders must understand the problems they are trying to solve and set themselves clear goals. Organisations easily fall into the trap of deciding to go agile because it is what their peers do, without fully understanding the ‘why’. Ensuring senior management support for the vision and purpose will help establish broader support and higher acceptance for the transformation, and help to make the communication strategy compelling. This is the essential first step. What then needs to be established is a clear understanding of agile principles at all levels of the organisation and thorough understanding of how business leaders can help their organisations deliver “better value sooner, safer, and happier”3 through high levels of engagement, inclusion, and empowerment. Short iterations and immediate feedback are key to enabling success on an agile journey.

A well-defined IT service portfolio is a good starting point to create a product portfolio and identify associated Value Streams. Value Streams are series of steps to build and support a set of solutions: the products, services or systems delivered to the customer.

IT services can be categorised into either: services providing value directly to the business as part of a continuous value stream (so-called products); or supporting services, which are normally invisible to the business or end-users, but are required enablers for successful delivery of the products.

Service delivery is then best organised along the product and supporting service portfolio. Products and supporting services need to fulfil different requirements as far as speed, agility and cost efficiency are concerned:

• products are at the core of value delivery to the business. Agility and speed are therefore paramount when meeting new requirements. An often chosen organisational setup is the product team. Product teams are long-standing cross-functional teams aligned to the product portfolio ( see also sidebar “What is a product team?”).
• supporting services are enablers and consumed by the product teams. They consist of specialist roles, people, and services required by the product teams. Supporting services are more technical
  (i.e. platform services), best delivered by teams of highly specialised IT engineers. Agile ways of working can be an option for these teams, but this needs to be determined on a case-by-case basis.

While the product team setup allows for highly empowered teams and maximum business-IT proximity, decentralisation of decision-making requires organisations to establish new cross-service portfolio governance concepts. Frameworks such as SAFe (Scaled Agile Framework) help to scale agile from team level to enterprise-wide adoption and provide insights into the enterprise-level governance required to ensure convergence of the company’s service portfolio. This also includes guidance on practices for strategy-alignment, budgeting and funding.

Self-service enablement is the core focus of the supporting services organisation. This helps the product teams to provide efficient delivery by providing them with fast, on-demand security, architecture and infrastructure provisioning. Cloud-based services minimise constraints from on-premise legacy infrastructure and therefore help to strengthen the self-service capability. Within the product teams, full automation of the end-to-end software development cycle is a prerequisite for the DevOps capability (see also sidebar “What is DevOps?”).

Today, IT organisations are primarily funded with a run and a change budget. As the organisation shifts to a product-based technology operating model, funds are allocated to products and allocations are not divided into run and change. With the help of so-called lean budgeting methods, the organisation can adapt more flexibly to emerging needs than with static yearly budgeting cycles. Leaders should focus on facilitating both development excellence and product innovation through a continuous investment mechanism by funding stable teams for a fixed duration.

Transforming a technology operating model is no small undertaking, especially since it touches upon both IT and the business alike. There are significant risks and pitfalls as new ways of working are established within a traditional organisation. As with any large change management initiative, the transformation requires long-term C-level and senior management commitment and support. A pilot approach is recommended to test the transformation hypothesis early and often and so minimise the risk of failure.