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 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 organisation. 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, 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@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 (e.g. Beyond Budgeting).

Business Agility: Organisations 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 organisation. 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 recognisable concepts. Personally, I think that over the next 5-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/frameworks like Scrum or XP? Let me know in the comments below…

-Evan, Singapore

Interested in knowing more about Business Agility in general? Come along to the Business Agility 2017 conference on the 23rd and 24th of February -