What do we mean when we say "we are Agile" (Don't forget to capitalize the A)? When you say Agile are you talking about the same thing I am? Do we agree when we say we are done our Agile Transformation?

No, we don't.

My definition of what it means for an team/department/organization/enterprise to be agile does not match yours. If you are an enterprise leader and I am a professional agile coach it is likely that our definitions of what it means to be agile won't even be close.

And it likely never will be.

A major reason we are unlikely to agree on what agile means is that many enterprise leaders choose to describe their agility in terms of an Agile methodology they are using.

Describing Agile as a Methodology

Here is a description many will ascribe to when defining what it means to be agile:

So if we adopt scrum, we are agile. And by adopt I mean we do the normative things scrum tells us to do:

  • we hire scrum masters and product owners, and optionally an Agile Coach
  • we work in time boxes
  • we have a backlog of product increments and user stories, and we work according to the priority of those backlogs
  • we do stand-ups, planning, reviews, and demos, strictly to a time box.
  • we estimate and measure using points
  • we plan, and track with burn down charts

Some people find this description of agile lacking, complaints include:

  • it's missing the organizational context
  • it uses unfamiliar jargon
  • time-boxes are unnatural for any but the most mature organizations
  • time-boxes are really just mini-waterfalls and cause abuse
  • it doesn't help with end to end value
  • people paint their waterfall mindset with scrum, and then call it a day

Occasionally you will see an organization describe Agile in a way that is closer to the software development roots where Agile came from, something like the following:

So if we can get extreme programming practices in place, with the really good software engineering practices it comes with, we are agile:

  • we have a team, and that team works in time boxes
  • we manage our work very similarly to the Scrum approach, burn down charts, tasks boards, etc
  • we work in pairs
  • we write tests first, we then write enough code to make those tests pass, then refactor our code to a better design
  • we automate our builds and integration testing using continuous tooling
  • extend our story driven delivery we saw previously with some robust development practices like TDD, Pairing, Continuous Integration

Again, people will say this description of agile is lacking, complaints include:

  • it is developer focused
  • developers hate pairing with each other
  • very few developers have the permission, discipline, or capability to do Test Driven Development or true refactoring
  • almost no enterprise software vendors make it possible to build solutions using agile engineering practices with their products

As we want to scale agile, we often start by scaling out the number of practices and processes we use.

Most likely we would want to "Install" a prescribed scaling framework like the below.

or If you are my age or older, you will have attempted something like this.

I wont even start to list all of the things that the enterprise needs to learn and do in order to even be able to comprehend and act on these more complicated descriptions of agile. I can list out some complaints I have heard about this, massively complicated description:

  • it is impossible for the lay man to learn, only process experts will take the time to understand it
  • the most anemic, thoughtless form of the methodology is what typically gets adopted
  • the process is still incomplete and misses major things required to increase agility
  • process conformance trumps process innovation
  • roles get converted to job families, accompanied by siloed, fragmented, and individualized responsibilities

Your description of agile may also be customized, custom built to the tastes of your Enterprise Leaders, here is one such version I built for a client:

Let's go over what is wrong with your customized agile method

  • it will be massively expensive to produce, typically built by expensive consultants like me
  • the leaders who oversaw its creation will like it, and everyone else will not
  • it will have all the same problems that the out of box methodology will have

The Agile Methodology Paradox

Adopting an agile methodology, even an amazing agile methodology will almost never lead to amazing agility in your enterprise

I have in the past loved, and I mean really loved, all, or at least most, of these agile methods above. And I continue to love some of them. I really love eXtreme Programming. And I love the custom one I built, that has all the awesome stuff in it I like doing, and I want others doing as well. I have had amazing experiences delivering better value with Agile Methodologies, I have grown my mindset and capabilities through learning them.

I have also watch people be indifferent, or outright hate these exact same methodologies. I have spent countless weeks - months building, teaching, and rolling them out. And then see very little of it stick, and I mean really stick, where it counted.

There is very little correlation between adopting an Agile method and Increasing the Agility of your Enterprise

Describing your enterprise agility using a methodology suffer from a number of problems. I'll list a few of them, I am sure I have missed a bunch of them.

  1. Prescriptive methodologies won't fit the context of your enterprise
  2. One static description of Agile will reduce the ability of individual areas within your enterprise to respond to change independently
  3. All methodologies are too complicated and too simple, at the same time
  4. People resent methodologies being enforced on them
  5. Enterprises like to "paint their organization" with an Agile methodology, than get back to being the same old enterprise
  6. When people ask you for an agile methodology they are avoiding the thinking required to be agile, you are starting on the wrong foot

The simpler agile methodologies leave a lot of concepts off the table, they ask you to fill in the Agile blanks, something that your average enterprise citizen is not equipped to do. Most often these blanks get filled in with traditional thinking. The more complicated ones, well frankly miss the point entirely. They prescribe a set of processes that try to address every conceivable step in your process, every unique situation you may encounter, every kind of work you might do. These methodologies, whether out of the box or custom rolled, collapse under their own weight. The Agile Process Guys love them, everyone else hates them, or at least do what ever they can to move around them.

I have seen to many examples where people are adopting these methodologies, or trying to, with little to no positive impact on their agility. Sometimes the impact is negative, very negative. I have seen organizations thrash with unfamiliar terms, poorly understood practices, and alien methodologies.

Anyone who tells you differently may just be selling you something. They may also be resigned to the fact that a sub-par, limited improvement in agility is all you can expect from your enterprise. I want to hope for a higher outcome, and hope you will to.

Up Next: Describing Agile as a Methodology

Note:

This article will appear, in some form, in my next book.

You can also access the entire work in progress version of the book on this page. Or better yet show your support by picking up a copy (really a table of contents at this point) here