What does it mean to be agile?

  • Is it about doing a specific methodology?
  • Is it about following specific practices?
  • Is it about doing things by the book?
  • Is it about certifications?

Those might be good entry points into learning to become agile. But, you can do all of those things and still not be agile. So, the question stands. What does it mean to be agile? 

Well, it depends on who you ask (and when):

  • Back in 2001, the authors of The Manifesto for Agile Software Development said being agile meant having a preference for working together directly, collaborating with customers, and responding to change in order to deliver working software.
  • Fifteen years later, Alistair Cockburn (one of the original signatories of the manifesto) began to describe the essence of agility in four words: collaborate, deliver, reflect, improve. He calls them the Heart of Agile.

Yet somewhere along the way, the word agile seems to have become synonymous with process, as in, “Yeah, we’re agile. We do Scrum.” That’s an incomplete picture of what it means to be agile. Process is important, for sure. But, it’s just one of (maybe) five aspects of agility, including:

  • Cultural Agility is the first prerequisite for becoming agile. It asks whether an organization’s values embrace agility. And, whether the culture lives up to those values. Without this, no implementation of Scrum or XP or any other methodology will result in true agility.
  • Structural Agility has to do with whether an organization is structured in a way that supports agility. Are teams truly cross-functional? And are they autonomous? These are critical aspects of agility that many organizations get wrong. They try to implement a methodology atop their existing organizational structure only to find that it doesn’t really make a difference.
  • Procedural Agility is about how work is planned and organized. Can teams rapidly, reliably, and repeatedly deliver significant value to their customers? Is the process iterative? Is it adaptive, i.e. can it handle changing requirements? If not, then the organization has yet to become fully agile.
  • Technical Agility addresses execution. It likely differs from domain to domain. In the world of software development, technical agility happens when engineers are able to move nimbly through the codebase, because the design is pliable and the code is backed by fast, reliable tests. And…
  • Environmental Agility takes into consideration the things that affect delivery that happen after execution is complete. In software development, that means having reliable, performant tooling to process code on its journey from development to production. It also means that engineers are able to self-serve when a problem arises.

For an organization to live up to the promise of agile software development, all aspects must be present. Every team is unique, of course. And as such, every team needs to discover together the practices that work best for them.

Over the last 25 years, I’ve encountered a few dozen practices that foster agility. Many that were controversial in the beginning are now considered industry standard best practices. Others might only be applicable in specific situations.

I intend to catalog the practices that have produced the best results for me over the years. This won’t be an exhaustive list of practices. It won’t be a playbook (though I might write one later). It won’t be a methodology. Rather, it will be more like a pattern repository that is heavily influenced by Kent Beck and Martin Fowler. My goal is to provide enough information for teams to decide whether a specific practice is something they want to try.

Industry standard best practices will be called out as such. It’s obviously up to you whether or not you use them. But when you choose not to, make sure you understand why you’re choosing not to, and what you’re doing instead to account for the missing benefits of that practice. And, be ready to communicate that information to your leaders.