Adopting Agile? You're aiming at the wrong target.

The adoption of agile development is a misguided, marginally useful, and probably doomed objective.

I’ve done a lot of agile transformation work, and on several occasions, I’ve found myself deeply involved in what I thought was an Agile Transformation initiative that just happened to be labeled as the company’s “Agile Adoption” initiative. These days you can’t swing a stick without hitting a large company with an “Agile Adoption” program in place, and that usually comes with an Agile Center of Excellence (COE), Agile Coaching Group, or Agile-PMO that’s charged with facilitating that adoption.

Some years ago, I thought that Agile Adoption and Agile Transformation were synonyms. I’ve learned the hard way that they’re not. And when a company pursues agile adoption, more often than not, they neither understand what they’re shooting for nor do they hit it. It has been my mistake in the past to confuse the two, and failing to help my company or client to recognize that setting your goal on the adoption of agile development is a misguided, only marginally useful, and probably a doomed objective for an organization.

Adopting Agile… misguided? You can’t be serious! The idea of adopting agile presumes that agile is a thing that can be adopted or implemented like a method, framework, or recipe. Furthermore it usually comes with the assumption that agility can be had by changing the way that some development teams work. Neither are true.

Here’s why: Agile is not something that can be adopted because it's not a set of practices or a method. For that matter, it shouldn't be considered a noun. It's an adjective, and more importantly it characterizes an organization. An organization can be very agile, or not so agile. But when an organization is agile it’s not because they’re "doing Scrum or Kanban, or XP, or [name your favorite framework]”. Those are tools, and they expose flaws in your organization that impede flow (i.e. impediments). When you remove those impediments – if in fact you ever do – then your organization becomes more agile as a result. So agile is a quality, and it results from removing the impediments that were constricting flow; its not the result of simply adopting a development method or framework.

Consider the analogy of Health. One cannot adopt health. One can become healthier. But what it takes to become healthy differs slightly from person to person. One person might become healthier by adopting a more active lifestyle – e.g. exercise, etc – because sedentary behavior was their biggest impediment to health. Another person might need to modify their eating habits to a healthier diet – because poor nutrition was the biggest impediment to their health. And a third person might need to more actively manage their insulin to be healthier. There can be templates that we can adopt, like a particular diet or a specific exercise regimen that works for many people. But the adoption of one of those things in and of itself is not the goal; improving your health is the goal. And adopting one or even all of them is not the equivalent of being healthy. We would never say that we’re adopting health.

To apply this to the context of Agile, you can adopt Scrum, but adopting Scrum is not the goal, and won’t necessarily make you agile. Scrum will expose impediments. Becoming agile hinges on whether you choose to change your organization to remove those impediments or if you “customize Scrum” to accommodate those impediments. Most organizations that I have witnessed over the years opt to change Scrum and accommodate their impediments. Think you’ve had more luck? Have you ever seen a development team/group that says “we can’t deliver user stories from the business in 2 weeks, so we break them down into our own stories that we can deliver but most of those so-called stories are technical and aren’t really recognizable to the business until we’ve delivered an aggregate of many of them over several sprints”? If you have then you’ve witnessed the customization corruption of Scrum. When adopting Scrum is the goal, we might be inclined to accept this corrupted form of Scrum and fail to remove impediments, thus fail to become more agile. Alternatively, when we learn to see becoming agile as the goal, and what it means to be agile – e.g. “the ability to turn on a dime for a dime”, as Craig Larman likes to say – then we’re more likely to see and address impediments when Scrum exposes them, rather than take short-cuts and change/corrupt Scrum. In other words, we’re more likely to become more agile.

The second point is that agility is not likely to result from merely [re]shaping the way that the development team(s) does its work. This is because the biggest impediments to the flow of value usually come from the organizational design, more so than the way a development team does its work. The way that teams do their work is shaped by the organizational design and culture. Trying to change the way a team does its work without addressing the underlying forces – i.e. organizational design – is a path to frustration and eventual failure. Exploring the kind of organizational design side effects that impede flow, is a large topic so I’ll offer just one example here: I’ve worked with a company where single development teams are incapable of completing a meaningful user-story from tip to tail without involving several other teams and/or single function groups to do some portion of the work – e.g. changing the database, UI design, getting permission to change a web-service, etc – and as a result, meaningful user stories involve putting items in the queue (aka backlog) of several different teams or groups, and waiting for them all to complete their portion of the work. This phenomenon is very common in the corporate world and is known as Conway’s Law. This debilitating condition has a far more constrictive effect on flow than any single practice of the teams themselves. The only fictional part of this account is that I said that it was “one company” that I worked with that had this problem, when in reality it’s nearly all of them.

In order for a typical large company, whose business requires substantial software development, to achieve some significant degree of agility, I would expect their strategic and operational planning will have to change, how they budget and fund projects will be completely reworked, the notion of projects will all but disappear, organizational structure will change, product management will be overhauled, roles and responsibilities rethought, the role of management will change from working in the business to working on the business, a new approach to product management, and the layers of structure that separate planning from execution will melt away, and yes... the development teams will probably engage with their business partners in a significantly different way. Other than that, not much changes at all ;)  Are you beginning to get a sense of why I say this is a transformation and not an adoption?

The more we express our goal as “Agile Adoption” then the more we think of the scope of our objective as just adopting an agile framework. That typically reduces our perspective to only addressing how the development teams work, and it distorts our sense of what the results should look like. When we think our objective is to adopt a framework, it leads us to the path of least resistance - e.g. changing Scrum to accommodate our circumstances.

Companies that have an agile adoption initiative in place usually don't understand agile, and don't realize that the goal of adopting a set of practices is not going to buy them very much. Only by removing the impediments to flow, which is usually a significant transformation of their organization, can they become more agile.