Agile is not the goal

The first thing you should think about when planning a transformation is: What is the organization trying to accomplish? The goal is surely not to implement agile software development. The goal is more likely to reduce time to market – the cycle time between when new business capabilities are needed and when they get released for use – in other words, the goal might be to achieve business agility, which is not the same thing as "agile" software development. Or the goal might be to “lean out” software development in order to increase the efficiency of IT – or both. Understanding the actual business goal, and focusing on that, rather than focusing on “agile”, is extremely important.

One challenge is that the term "agile" is often ambiguous. According to Michal Vallo, Agile Coach and founder of Aguarra,

"As Agile is not very well defined within community, there are two approaches. If Agile means use of particular process or technique (e.g. Scrum), then yes, Agile is not the goal. There is underlying business problem and we try to tackle it. If Agile is seen as approach, how to manage modern knowledge base company, which aims at setting environment, culture and engagement of employees, then Agile, IMHO, is the goal."

(Those interested in more of Michal's thoughts on this should view his insightful presentation, Four Layers Of Agility.)

Let's talk about what "agile" means. An agile organization is an organization that has business agility. That means responding quickly to the market, and also anticipating changes in the market. It means having the right amounts of liquid capital available for unexpected investments, and it means positioning the organization strategically. In the IT world, the term "agile" has a very special meaning, and generally refers to the doctrine articulated by the Agile Manifesto. The Agile Manifesto - and the bulk of the original agile IT literature - speaks to team level issues - not specifically to organization level issues. Attempts to extrapolate the Agile Manifesto and agile team practices to organization level issues have had mixed success, and the reasons for and solutions to that are the central purpose of this website. Further, there is no consensus in the agile software development community about what it means for an IT program to be "agile", or what it means for an organization to be "agile", in the context of the Agile Manifesto.

Being clear on the goals is important because if the goals are not clearly articulated, then agile coaches - the primary agents of agile transformation - can easily focus on the wrong things. In the absence of clear guidance, they will tend to focus on "agile" as they know it, with a heavy emphasis on agile "ceremonies" (standup meetings, etc.) rather than looking at what the real issues are. According to Buck Kulkarni, an Enterprise Process & Governance Architect, "Organizations are killing themselves with these words and rituals." That is, the goal can become adhering to agile rules rather than solving the challenges that the organization actually has: and the challenges can be very different from one organization to another. Brute force adoption of agile process rules can often result in even worse situations, such as having a Scrum master for a team of one programmer.

When supporting an agile transformation, agile coaches therefore should not be constrained by the Agile Manifesto or by any particular agile model such as Scrum: they need to look to other sources of information and resources that address the issues of business agility, organization transformation, and organizational behavior. According to Maura van der Linden in Coaching Is the Key for Scrum Success,

• Coaches examine organizations, teams and individuals to see what they are doing and how, both in Scrum implementation and in other processes or facets of how they do their jobs.
• Coaches teach Scrum practices but also teach a variety of other methodologies that may be needed to help the team or organization succeed.

And coaches certainly should not assume that if one were to apply agile software development practices to the business as a whole, that it would work. Agile software development practices were designed for the unique challenges of software development projects, and specifically for small teams: that is their sweet spot. Some ideas and practices might work in other parts of the organization, or in other domains, but this is not to be taken for granted. There are many other schools of thought that are applicable to business level and organization transformation issues, and many of those are discussed on this website. "Agile", as in the Agile Manifesto and agile software development, is not the full answer to how one can give an IT function more business agility.