Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Domains of Agility

DZone's Guide to

The Domains of Agility

I think that over the next five to 10 years, we'll see an explosion, then consolidation, of business agility frameworks and methods.

· Agile Zone ·
Free Resource

The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.

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.

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap, brought to you in partnership with Techtown Training

Topics:
agile ,scrum ,business agility ,agile implementation

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}