Throughout my consulting career, I’ve frequently encountered the term “transformation” being thrown around excessively in IT circles. Virtually every organization is undergoing some form of transformation, whether it’s related to agility, digitalisation, or cultural change. To gain a genuine understanding of what transformation entails, it’s crucial to delve deeper and clarify some of the commonly used terminology.

Transformation is a word used to signify intent to make a change, often triggered by an imminent business disaster that is going to affect bottom lines or by a change in the executive. It is generally driven from executives who have a sense of urgency e.g. being driven out of business due to disruption caused by new players in the market. Making things digital is what we did 30 years ago. We replaced tapes with CDs, letters with email and paper based calculations with spreadsheets. Digital transformation is not about making things digital but about modelling your business around technology. Considering technology not merely as a business support function or a commodity available for purchase from an IT vendor, but as a key differentiator to gain deeper insights into customer behaviors and steer your market strategy. This involves modernising your technology stack to unlock data from legacy systems (e.g., through APIs), externalising it to collaborate with partners, and creating novel business opportunities. It also entails providing services to customers anytime, anywhere, and on any device. Additionally, it may involve establishing a data-driven business by combining data from various sources, constructing analytics models for predicting and optimising outcomes, and subsequently transforming the business based on these models to enhance the return on investment from data.

Agile transformation

Driving business change through agile transformation is modelled around aligning people, processes and products.

  • people - cultivate a supporting environment that emphasizes learning from failures rather than blaming. Setting up teams to succeed by providing them time, space and resources to experiment and learn.
  • processes and tools - adopt processes and tools that help in continuous improvement and better collaboration by breaking silos within the business
  • governance - manage investment risk to
    • understand where your IT spend is going. Are you tracking cost, time and resource allocation efficiency or tracking speed and value?
    • improve delivery assurance by measuring the progress on your plan
  • customer - manage stakeholder expectations and improve product decision making by factoring in
    • opportunity cost - explore multiple options to understand the potential missed opportunities foregone by choosing one option over another.
    • cost of delay - ensure product decisions are made not just by understanding the value of something but also its urgency.
  • money - move from annual investment cycles to beyond budgeting, switch from cost accounting to throughput accounting
  • organisation - changing the organisation structure and culture to optimize for delivering value to your customers

Simply put agile at scale means breaking up large projects into small pieces, so you can release to the market faster, run experiments, get customer feedback and deliver something that the market wants rather than deliver what you think that they may want. This focus on delivering quickly in small increments reduces risk. An all or nothing approach is required if you are launching a rocket into space, not when you are delivering an improvement over your existing website.

Cultural transformation

Culture is often what people do organically, it is not what you say, it is about what you do. It is about specific behaviours that help in building effective teams e.g.

  • having a shared purpose
  • establish safety and openness - ability to express vulnerability and know each others background, goals, strengths and weaknesses
  • discourage blame - say no to talented jerks - scientific experiments have shown jerks diminish a team’s performance by 30-40%
  • keep the culture alive (culture capture) - seek and provide constructive feedback. What excites the team, what frustrates them, what is their biggest challenge?

Applying the agile principles in practice without worrying too much about the methodology is critical to being agile rather than doing agile. Too much emphasis on process, stops people from thinking what they are doing and whether they are doing it right. For example, the value of processes like daily standups is their ability to create a safe space for team-members to hold each other accountable against the shared objectives rather than perform a daily morning ninja routine of what I did yesterday and what I will be doing today.


If you want to go fast travel alone, if you want to go far travel together

Organisational structure is important in managing accountability and fixing responsibility within teams but obsession with tightly defined structures and roles ends up creating barriers amongst your teams. The goals across teams sometimes vary vastly and may even be contrary to each other. This can result in organisational silos e.g Development teams want to push new features and functionality quickly to customers where as Operations want the systems to be resilient and can be averse to rapid change. Balancing velocity against risk is a fine art and often safety trumps new thinking. This siloed thinking has a direct effect on the kind of systems built within your organisation.

Opening a dialogue between disparate teams is as much a cultural change as it is an operational one. Having small, self empowered (often collocated) cross functional teams with experts from across the business, drives collective responsibility and ownership of:

  • issues/problems that the business faces
  • results and successes
  • as well as failures

Autonomy and alignment

Everyone wants autonomy, everyone wants to have freedom to do what they like, but there are always boundaries to everyone’s autonomy. In a team, my autonomy might start to step on somebody else’s autonomy, and so we need to form an agreement, expectations.

Don’t mandate how a team should work. Don’t say, “You have to do stand ups. You have to do one weekly iterations. If you want your teams to be very agile and adaptive focus on the outcomes rather than output. We want to make sure that all code has automated tests, we want to make sure that you do frequent releases, and we expect that, but how you would like to do that is up to you and your team. We’re talking about the boundaries of autonomy.

Autonomy may also result in reactive solutions to problems. This is where alignment becomes important, because when you’re in a larger organization, and you’re moving from Start Up to Scale Up, everyone is normally aligned to working on the most urgent thing. In a very early-stage startup, that most urgent thing constantly changes, and as you get bigger and bigger, you need to create levels of alignment.

Embracing failure

Learning is the result of every experiment that you run. Failure is learning.

The impact of a failure isn’t necessarily bad, provided you learn from it without paying a heavy price. You can think of failure as a means to blame someone or an opportunity to expose underlying problems so that they can be fixed. If you can get small incremental changes out to customers frequently, you allow yourselves the ability to fail fast and learn cheaply.

The reason why we couldn’t do it - because of such and such thing e.g. The reason we couldn’t drive customer sales up because our assumptions about customer’s online usage patterns were wrong.

Measuring success

There are various aspects of measuring success - cost, modernisation that leads to improvement in quality and performance.

Being able to identify successes and failures is essential to gathering feedback when developing new processes. Many businesses find it very difficult to visualise information or value flow across the organisation (value stream mapping). Without this information, the only lever left with business managers is cost. The most important question then becomes: Where is my spend going? Whether that spend actually delivers customer value becomes an inessential concern.

Focus on cost utilization means that IT budgeting decisions are based on cost estimation of your portfolio. During the planning phase the budgeting exercise allocates fixed amount of money (in batches) to one or more programes consisting of smaller projects. With the budget allocated and the cost fixed we then expect teams to deliver all the agreed features that we think customers want. However, if customer feedback loops have been established via continuously and incremental delivery methods, they may tell you a very different story about what the customer’s actually want.

Obsession with cost utilization (which is essentially a measure of people busyness) leads to misplaced priorities and bad decisions. Time spent becomes more important than the result. Anything that doesn’t generate revenue becomes a cost centre, IT teams end up being treated as cost functions rather than centres of value addition.

Doug Hubbard in IT measurement inversion suggests that cost has a very limited effect on return on investment whereas the utilization of the system i.e. whether the system is actually going to rollout and whether anyone will use it at all, is the most important factor for ROI analysis.

One way of measuring value of features is using cost of delay - how much is it costing you in per unit time to not deliver a feature? Everything is measurable article explains how to measure intangibles or measure anything

Creating feedback loops

How do we know what we are building is the right thing faster? Whether the assumptions we are making are correct? How do we quickly test those assumptions?

A lean business can cheaply find out whether people are going to use new features in a system by running small experiments.

  • Tackling the most important problems that add value, not optimizing for the case where we think we are right (For established products, with a well proven business model, two-thirds of the time the features that we want to build have 0 or negative value. In new product development 90% of the time they have no value)
  • By creating feedback loops to validate assumptions
  • By delivering in small increments
  • Enabling experimental approach to product development using a scientific method

One of the ways of achieving this is using hypothesis driven delivery

We believe that [building this feature] [for these people] will achieve [this outcome] We will know we are successful when we see [this signal from the market]


The path to digital transformation involves dismantling organisational silos by fostering collaboration and establishing cross-functional teams with shared goals. These teams become conduits for rapid experiments and crucial feedback loops, measuring the value derived from these initiatives. Shifting away from traditional budgeting and throughput accounting to reorganize around value streams, flow, and a customer-centric approach is essential. This strategic realignment not only deepens the understanding of customer values but also opens opportunities to rethink outdated processes and create innovative customer experiences.