During my consulting career I have often come across the term transformation being banded about ad nauseam in IT circles. Virtually every organization is going through some sort of transformation, be it agile, digital or cultural. To truly understand what transformation means, it is necessary to dig deeper and clarify some of the terminology that is often used.

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. Thinking of technology not as a business support function or a commodity that you can purchase from an IT vendor but as a key differentiator to better understand your customer behaviors and drive your market strategy. This can mean unlocking data sitting in legacy systems (e.g. via APIs) and externalising it to work with partners to create new business opportunities by providing a service anywhere, anytime and on any device. It could also mean building a data driven business that combines multiple sources of data across the business, builds analytics models for predicting and optimizing outcomes and then transform the business based on the models so that data yields better return on investment.

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 reporting app.

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]


Breaking down organizational silos through collaboration, creating cross functional teams with shared objectives that can run rapid experiments and create feedback loops for measuring value from these experiments. Moving an organisation beyond budgeting, throughput accounting and rebuilding it around value streams, around flow and around customers allows you to understand what your customers really value and provide opportunities for reimagining old processes and building new customer experiences.