The Domains of Agility

Agile doesn't just mean Scrum and agility doesn't just mean Agile. Over the last few months, I've been forming a simple model of agility and looking at how different elements interact with each other. To that end, I want to introduce you to the three different forms of agility that I believe work in concert to create an agile organization: technical agility, process agility, and business agility.

This has emerged out of the work I've been doing on the Business Agility Conference, trying to understand how traditional Agile fits in.

Process Agility

I'll start here because this is the form of agility that most people think of when they hear the term. This is the form of agility that wraps projects and teams to deliver work. Think of it as an individual value stream. Scrum, SAFe, and LeSS are all, in large part, operating at this level (although it's true to say that many of the larger and more complex Agile at scale methods operate in the business agility domain, as well).

Technical Agility

For decades, Agile teams have promoted strong technical agility as the keystone for "being" Agile. In fact, one of the founding agile frameworks is Extreme Programming (XP), a framework almost entirely devoted to technical agility. Many of the techniques we use today trace their origins to XP — test-driven development, pair programming, even refactoring. Technical agility isn't limited to just software, either. Any domain of work can be "technically" Agile. For example, we're starting to see agility emerge in finance teams with their own agile technical practices (i.e., beyond budgeting).

Business Agility

Organizations are only now starting to think about business agility as a discrete domain. Over the last 20 years, as individual teams became agile, the constraining factor for agility was the other teams within the division. Now, as entire divisions and departments become Agile, the constraining factor for agility is the rest of the organization. In my experience, Finance, HR and the PMO (as well as business leadership) are usually the immediate constraints. Thus, we introduce business agility.

Business agility remains an emerging model, so there isn't the same level of formal practices and frameworks that you find in other domains. Beyond budgeting, holocracy, and servant leadership are probably three of the most recognizable concepts. Personally, I think that over the next five to 10 years, we'll see an explosion, then consolidation, of business agility frameworks and methods.

This is still a work in progress, so I'd appreciate your thoughts and comments. Does this approach align to your model of agility? How do you think business agility interacts with common practices and frameworks like Scrum or XP? Let me know in the comments below.