Digital and continuous change: agile and transformation offices

Most of the theories in lesson 2 picture change as a project: it starts, runs through stages and ends. Dr. Morin points out that this picture fits fewer organizations each year. Software is updated weekly. Customers' expectations shift with every new app they use. Cedarline's digital roadmap is not a project with an end date but a permanent shift towards a company that improves its systems, processes and services continuously. Grace's new venture, Second Ascent, will change its repair process, pricing and service every month as it learns what customers want. Even Daniel's plant, where change once arrived with a new model year, now adjusts its processes daily using data from the robotic cells.

This lesson examines how organizations build the capacity for continuous change, how agile methods have spread from software into management, and how large transformations are coordinated through transformation offices without strangling the continuous improvement they are meant to enable.

Continuous improvement

The oldest form of continuous change in management is continuous improvement, rooted in the statistical quality work of Walter Shewhart at Bell Laboratories in the 1920s and spread by W. Edwards Deming and others, especially in Japan after the Second World War. Its core is the plan-do-check-act cycle: plan a change based on a hypothesis about a problem, try it on a small scale, check the results against the prediction and act by adopting, adapting or abandoning it. Toyota built the cycle into the daily work of every team, under the name kaizen, so that improvement became part of everyone's job rather than a special project.

The power of continuous improvement lies in accumulation. A team that makes one small improvement a week for a year has made fifty, each tested, and the combined effect can exceed a single large redesign. It also builds capability: people who improve their own work learn how the work functions and gain confidence that change is something they do rather than something done to them. Its weakness is that it optimizes the existing system and may not produce the discontinuous changes that a new strategy requires. That is why most organizations need both the episodic and continuous modes described in lesson 2.

Agile beyond software

Agile methods began in software development. The Manifesto for Agile Software Development, written in 2001 by seventeen practitioners, valued individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Methods such as Scrum organize work in short cycles, called sprints, typically two weeks long. A small cross-functional team works from a prioritized backlog, delivers something usable at the end of each sprint, reviews it with users and holds a retrospective on how to work better.

From the 2010s, organizations began applying agile principles beyond software. In 2015 ING, the Dutch bank, reorganized its head office in the Netherlands into small multidisciplinary squads grouped into tribes around customer missions, with chapters connecting specialists of the same discipline across squads; executives described the change in interviews published by McKinsey in 2017, and it became a widely studied example. Other organizations borrowed the 'Spotify model' of squads, tribes, chapters and guilds, described in 2012 by Henrik Kniberg and Anders Ivarsson for the music streaming company. Kniberg himself later warned that the model described a moment in Spotify's evolution, that the company never fully implemented it as drawn and that copying it as a template missed the point.

Dr. Morin draws three lessons from the spread of agile. First, agile is a way of managing uncertainty: it works best where requirements cannot be known in advance and learning from users is essential, and it adds little to work that is well understood and stable. Second, agile changes management roles more than team roles. Managers stop assigning tasks and start setting missions, removing obstacles and developing people; executives must accept that plans will change as teams learn. Organizations that adopt agile rituals while keeping command-and-control management produce what practitioners call agile theatre: stand-up meetings and sticky notes without the substance. Third, agile is itself a change that must be led, with all the issues of readiness, coalition, design and culture covered in this course.

Ambidexterity

Charles O'Reilly and Michael Tushman described in 2004 the ambidextrous organization: one that exploits its existing business efficiently while exploring new businesses that may eventually replace it. Exploitation favours discipline, efficiency and incremental improvement; exploration favours experimentation, tolerance of failure and speed. Putting both in the same unit usually means that exploitation wins, because its returns are nearer and more certain. O'Reilly and Tushman found that successful companies typically separated exploratory units structurally while integrating them at the senior team level, where leaders allocate resources and protect exploration from being starved by the core.

Cedarline faces this tension directly. Its core business of designing, sourcing and selling outdoor clothing must become leaner and more disciplined. Its repair service, the Cedarline Care membership and its stake in Second Ascent are exploratory. The MBA-603 roadmap placed Cedarline Care in a separate unit reporting to the chief executive with its own budget and growth targets, which is the structural separation O'Reilly and Tushman recommend. The change plan must make sure that the core's cost discipline does not quietly absorb the exploratory budget.

The transformation office

When a company runs many changes at once, someone must coordinate them. The usual answer is a transformation office, sometimes called a transformation management office or program office. Its job is not to run the changes, which belong to the business units and functions, but to make the portfolio work as a whole. Dr. Morin, who ran one, lists its functions. It maintains the portfolio: what initiatives exist, who owns them, what they will deliver and when. It manages dependencies and sequencing, including the change load analysis of lesson 7. It tracks benefits against the business case, using leading indicators of adoption as well as lagging financial results. It runs a regular rhythm of reviews in which initiative owners report progress and problems to the sponsor. It escalates conflicts over resources. And it maintains change management standards, so that communication, training and support are planned consistently.

Transformation offices can also go wrong. Dr. Morin describes three failure modes. The reporting machine produces elaborate status reports, marked red, amber and green, that consume initiative leaders' time and tell the sponsor little, because every initiative reports green until it suddenly turns red. The bottleneck requires approvals for every decision, slowing the very changes it exists to accelerate. And the parallel hierarchy builds its own power, staff and agenda, competing with the line managers who must own the changes. The remedies are to measure few things that matter, especially adoption, to push decisions to initiative owners and to plan the office's own dissolution once the changes are embedded.

Tracking benefits with leading indicators

A common weakness of benefits tracking is that it relies on financial results, which arrive months or years after the behaviour that produces them. By the time markdowns show that the range reduction is not working, a season has been lost. Good tracking pairs each financial benefit with leading indicators of adoption and behaviour: the share of stores using the new replenishment schedule, the share of planners' forecasts made in the new process, the share of sales with a repair option offered. If adoption indicators are on track but financial results are not, the business case may be wrong. If adoption is behind, the change is not yet happening, and the problem is one of leadership, support or design, not of the business case.

Cedarline's transformation office has defined, for each of five workstreams, a planned adoption level for the end of the first two quarters and a target benefit for the year. Dr. Morin shows how to turn the reports into an early warning.

# Benefits tracking with leading (adoption) and lagging (financial) indicators
# workstream: (adoption planned, adoption actual, benefit planned to date, benefit actual to date), thousands of dollars
report = {
    "range and promotions":   (0.80, 0.78, 900, 610),
    "planning (S and OP)":    (0.70, 0.45, 400, 180),
    "weekly replenishment":   (0.60, 0.62, 300, 320),
    "durability and repair":  (0.50, 0.30, 150, 60),
    "people (DC spans)":      (0.90, 0.90, 200, 190),
}

def status(a_plan, a_act, b_plan, b_act):
    a = a_act / a_plan
    b = b_act / b_plan
    if a >= 0.9 and b >= 0.9:
        return "on track"
    if a >= 0.9 and b < 0.9:
        return "adoption fine, benefit lagging: test the business case"
    if a < 0.9 and b < 0.9:
        return "adoption behind: fix leadership, support or design"
    return "benefit ahead of adoption: check measurement"

print(f"{'workstream':24s} adoption  benefit  diagnosis")
for name, (ap, aa, bp, ba) in report.items():
    print(f"{name:24s} {aa/ap:7.0%}  {ba/bp:7.0%}  {status(ap, aa, bp, ba)}")
total_plan = sum(r[2] for r in report.values())
total_act = sum(r[3] for r in report.values())
print(f"portfolio benefit to date {total_act} of {total_plan} planned ({total_act/total_plan:.0%})")

workstream               adoption  benefit  diagnosis
range and promotions         98%      68%  adoption fine, benefit lagging: test the business case
planning (S and OP)          64%      45%  adoption behind: fix leadership, support or design
weekly replenishment        103%     107%  on track
durability and repair        60%      40%  adoption behind: fix leadership, support or design
people (DC spans)           100%      95%  on track
portfolio benefit to date 1360 of 1950 planned (70%)

The portfolio as a whole has delivered about 70 per cent of its planned benefit, which a traditional report would show as one amber light. The leading indicators tell a more useful story. Weekly replenishment and the distribution centre spans are on track. The range and promotions stream has been adopted as planned but is delivering less benefit than expected, which suggests the business case was optimistic, perhaps because customers who used to buy on promotion are buying less rather than paying full price; the steering group should revisit the estimate rather than push store staff harder. Planning and the durability and repair stream are behind on adoption. Planners are still building forecasts in their old spreadsheets, and store associates are offering repair options on fewer sales than planned. Those are problems of leadership, support and design, and lesson 11 takes them up.

Digital change

Digital initiatives have some particular features as changes. Their adoption can be measured directly from system data: who logs in, which features are used, how often workarounds occur. That makes leading indicators cheaper and more precise than in other changes, though measuring individuals' use raises the privacy and trust issues discussed in lesson 9. Digital tools can also be changed quickly in response to users' feedback, so adoption problems can often be addressed by changing the tool rather than the people. And digital changes often alter power: a forecasting system that replaces store managers' judgement, or a documentation system that records consultations, changes who knows what and who decides, which is why they provoke resistance out of proportion to their technical scale.

Hana's experience at Lakeview shows how these features can be used. When the hospital looked at the documentation system's usage data, it found that physicians who stopped using it had typically done so after editing three or four long drafts in their first week. The vendor added a feature that let physicians mark recurring errors, which the system then avoided in future drafts. The hospital then asked the two emergency physicians who were already champions to run fifteen-minute sessions on fast editing during shift changes. Within a month, twelve of the physicians who had stopped were using the system again.

Building change capability

The deepest goal of continuous change is an organization that can change without needing a transformation program each time. Peter Senge's 1990 book The Fifth Discipline described the learning organization, in which people continually expand their capacity to create the results they want, through personal mastery, shared mental models, shared vision, team learning and systems thinking. David Teece and colleagues described dynamic capabilities, the organizational ability to sense opportunities and threats, seize them and reconfigure resources. Both ideas are easier to describe than to build, but they suggest what a transformation should leave behind: not only new processes but people who know how to change them.

Dr. Morin suggests some practical markers. Teams routinely run small experiments and share results. Managers ask what was learned, not only what was achieved. Problems are surfaced early rather than hidden, which depends on the psychological safety that Amy Edmondson's research has linked to learning in teams. Improvement ideas from the front line are acted on quickly. Data on how work is going are available to the people doing it. And when a change is completed, the organization reviews what it learned about changing, so that the next change starts from a higher level of skill.