Sunday, April 12, 2009

The Agility Cycle - Part 1

Continuing the "What is Agility?" series of posts ... we have looked at business agility and how it combines with the "people factor" from the agile manifesto to yield software development agility. So now that we know the meaning of agility, the next two questions  I want to answer are "how do you do it?" and "what does it look like?"

In this posting I will attempt to generally answer the "how do you do it?" question. This is basically a question of process. What is the overall process for "swiftly sensing and rapidly responding to change & uncertainty in close collaboration with stakeholders to create simple, sustainable structures with sufficient flexibility to dynamically adapt & evolve business processes, products & plans."

This process is essentially an overall cycle. Something that you do, and then "rinse, lather & repeat." It is called the Agility Cycle. Let's look at a few different descriptions of this cycle (mostly from the realm of business agility) and then formulate our own for software development agility.

Gartner describes the business agility cycle as:

  • Sense the need for change in the environment (includes the proactive initiation of change)
  • Strategize the available options and develop alternatives
  • Decide which path to take and commit to the approach
  • Communicate internally and externally to everyone who needs to know
  • Act to produce results and follow-through efficiently
Gartner has a number of reports on agility (some of which are even freely available :). You can read about them all at this summary.

John Boyd describes it as an OODA loop:
  • Observe your environment (yourself; your threats and opportunities; the physical, mental, and ethical situation; and potential allies and opponents)
  • Orient yourself to grasp what it all means and identify patterns, approaches and likely outcomes
  • Decide upon a course of action and tactical plan
  • Act on the plan (execute while minding the terrain)
Another source describes it as:
  • Scan emerging trends and issues through gathering information and analysis
  • Sense opportunities to translate information into actionable solutions
  • Respond to opportunities and risks by being sufficiently flexible at tactical and strategic levels
  • Shape future environments through driving change.
In Sense, Respond and Learn, Marcel v Oosterhout describes the business-agility cycle as:
  • Monitor & Sense: monitor the business environment and sense critical market signals, events, and changing conditions
  • Interpret & Evaluate: interpret the information and evaluate if it is something to (re)act to or ignore.
  • Decide & Plan: decide which response is best and plan to implement it
  • Reconfigure & Adapt: reconfigure or adapt business, operations, or IT capabilities
  • Respond & Execute: respond by executing with new or adapted capabilities
  • Learn: Record the cycle, learn from previous cycles, share to improve future cycles
  • Manage: manage the sense-respond-learn cycle to support completing the process as rapidly and effectively as required
Notice that, as with the definitions of business agility we saw before, there is no explicit mention of the kind of close collaboration and self-organization that is deemed an essential component of software agility. Any attempt we make to derive the software agility cycle from the business agility cycle needs to take into consideration this close collaboration of the participants and emergence of the solution as a result (rather than knowing it all up front).

We'll discuss this next time when we try to describe the software agility cycle.


galleman said...

What I like about every one of your examples is the complete absence of "management or no management."
Having attended an AfterBurner seminar, what the Boyd cycle is used to derive a slightly different approach, based on current fighter pilot tactics applied to sales, management, and project management - something suprising results.
The absolute ruthless application of discipline in the execution of the project, sales process, or management paradigm.
"Flawless Execution" is the title of AfterBurner's approach. Worth a look.
Keeping agile is a matter of survival. But doing so means strong discipline, continuous feedback, deep planning, briefing, and debriefing.
Keeping the politics of "no managers" out of the discussion moves these approaches into the "actionable" domain.

Brad Appleton said...

Very interesting comment. I think most of the definitions say little about "management or no management" because they are focused more on knowledge/learning than on formal authority.

I do think that the Gartner cycle, with its clean separation of deciding and communicating and then acting, may strongly suggest (to some at least) that management primarily controls the deciding and communicating, and then involves the "workers" to execute after the decision is made.

However, although that could be easily inferred by someone, it need not be the case. It's just hard not to make that assumption when the act of communicating to enage others doesn't occur until after the decision is made.

Ryan Shriver said...

Hi Brad,
I think the Business Agility cycle is as simple as:

1. Plan
2. Do
3. Study
4. Act

All others are consultants' takeoffs of this classic Deming process. Its got a long track record of success.

This cycle should be done within the context of a set of clearly defined principles. Such as:

1. Maximize Stakeholder Value
2. Clearly Define Desired Results
3. Deliver Value Early and Often
4. Pay for Performance (No Cure, No Pay Contracts)
5. Respect for People

Agile, and I suspect your Agility Cycle, is describing a means to an end, it doesn't include in scope the ends. No?

Brad Appleton said...

Hi Ryan! Thanks for chiming in. Your observation is similar to one I made in part 3 of my series on the agility cycle.

I think the word choice in business-agility cycle places a bit more emphasis on communication and responsiveness to change/feedback.

It's interesting to note that business/organizational agility (which pre-dates the agile manifesto) evolved directly from the likes of Deming and work of others, work on Learning organizations (Senge), and work on leading organizational change (e.g. Connor, Kotter, etc.).

Those are some of the same roots as Lean, and Lean has apparently evolved/matured more (or at least become more popular/trendy).

That's enough to beg the question of whether or not there really is any effective difference between Lean and Business-Agility, or if the former is just the latter put into practice.

ali anani said...

Hi Brad,
This is an interesting post. At least it takes out the ambiguity of using different terminology for the same thing.

I have a question: do you think agility is enough, or that it should be followed by adaptability? Being agile without adapting may be not enough. Have you done any work on this issue?
Thanks and bear with me asking more than one question

Brad Appleton said...

Hi Ali!
I think being agile implies being adaptive (and "inspect and adapt" is a well known mantra of the agile method known as "Scrum"). So in my mind you can't be agile without being adaptive. Being adaptive is one of the necessary traits of an agile project.