What Is Agile Transformation?

Agile transformation is the process of converting an IT organization from 1990s-era methods, primarily organized around sequential step-by-step processes, to "agile" methods that support continuous delivery of software in a lightweight and fluid manner.

The process is more important than the goal: changing how an organization works is very hard, and the goal inevitably goes through substantial changes along the way.

Why Is It So Hard?

There is a very humorous cartoon on YouTube called “I want to run an agile project”. It depicts a young and enthusiastic project manager who sets out to run an agile project in an organization that is not accustomed to agile. The video follows the poor project manager as he goes from department to department trying to overcome one institutional barrier after another.

Of all the barriers that he encounters, only one pertains to the software development team: it is a scene in which he tries to convince two team members to pair and collaborate. All of the other barriers have to do with policies and rules that the organization has – rules that impede the agile process.

This is why agile IT transformation actually has only partly to do with agile teams: it has much more to do with the way that various organization functions are run, including IT and its internal functions, as well as external functions such as contracting. (See Most Impediments Are Management Level - Not Team Level.) Agile transformation consists of convincing and educating these various stakeholders; it also consists of training teams and coaching teams, but if one does not give equal – or greater – attention to the impediments that are external to the teams, then the transformation will proceed very slowly and possibly lose momentum.

The problem of agile transformation is therefore not so much a problem of scaling agile: it is a problem of enabling agile. Scaling pertains to having many teams on a project, or coordinating multiple agile projects. That is certainly part of the problem of becoming agile, but becoming agile must also address how teams are supported by the various IT support functions that large IT organizations have, including data center operations, enterprise architecture, IT risk management and governance, IT security, data architecture, release management, IT portfolio management, and so on. Many of these functions need to change to accommodate agile, but these changes are huge and impact the missions of these groups, and so this change must be worked in a gradual and inclusive manner. This is an enterprise change management process – often the province of management consulting – informed by agile values and practices. It is much more than “scaling agile”.

In undertaking an agile transformation, one must focus on the business goal. The goal is not to implement agile, or to implement lean thinking, or any other paradigm: that is not a business goal. Rather, the goal is usually to make the organization more nimble (“agile”, in the dictionary sense) – i.e. to increase business agility and reduce waste. Business agility is not the same thing as agile in the sense of agile software development. Agile software development is a tool for enabling business agility, but business agility is more than that and differs in many ways. Some business agility strategies rely on significant command and control – approaches that are antithetical to agile software development. Melding agile software development with the way the rest of the organization works, so as to enable business agility – and doing so with approaches that are compatible with the strategies that are being adopted by the other parts of the organization – is the challenge of an agile IT transformation.

It is also important to realize that there is no single thought paradigm for realizing agile business goals: not Agile (as in Agile Manifesto), not Lean, not anything in particular. In fact, many of these paradigms have their roots at more fundamental levels that are worth exploring: e.g., Lean is deeply informed by “systems thinking”, which is really nothing more than stepping back and taking an objective end-to-end view of all factors of a problem and trying to understand how all these factors interact, and then discerning the critical paths and the constraining factors. It is just critical thinking; and more than anything, critical thinking is what is needed to plan and execute a transformation: one cannot simply apply some framework or methodology or paradigm and expect results. Judgment is required at every step.