We have 4276 guests and 4 members online

Video Spotlight

Home > Blogs > Featured Blogs > Brad Appleton's ACME Blog > The Agility Cycle - Part 1

The Agility Cycle - Part 1

 E-mail
Written by Brad Appleton   
Sunday, 12 April 2009 01:36

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 questions two 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
Once again, I'll refer to Jim Highsmith to represent the perspective that software development adds to the mix, namely the "people and collaboration" component. In his book Adaptive Software Development, Highsmith compares software development to a complex adaptive system (CAS) and uses CAS with elements of chaos theory and complexity science to derive the critical importance of people and collaboration in software development. He does this using the concepts of intelligent agents, self-organization and emergence within a turbulent (ever-changing, complex and seemingly chaotic) environment:

  • When we treat people as "intelligent agents" who both cooperate and compete to get work done in a turbulent environment, the final outcome is not the result of the work from any particular individual or process.

  • The outcome instead emerges from the interaction between the collaborating individuals to produce a result that cannot be predicted from their individual behavior (it is non-linear, defying simple cause-and-effect reasoning).

  • The details of the collaboration (and the final solution) cannot be pre-ordained and then commanded-and-controlled

  • Instead, successful collaboration and creativity must be nurtured, and must trust and empower the individuals to direct and organize themselves together "in real-time", learning and adjusting as they go.

This is the phenomenon of emergent behavior from self-organization to achieve successful results and adapt to unpredictable circumstances.

So 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 that more next time when we try to describe the software agility cycle.

The Agility Cycle - Part 1

Posted: 2009-04-12 09:36:00

Read Full Article
Author:Brad Appleton

Comments (0)Add Comment


Write comment

feedShow/hide comment form
You must be logged in to post a comment. Please register if you do not have an account yet.

busy
< Prev   Next >
 

Agile Marketplace - Announcements and Special Offers

Webcast:  Moving Build and Code Quality Upstream
This interactive panel discussion moderated by Bob Aiello, Editor-in-Chief fo the CM Journal brings industry experts Anders Wallgren, CTO of Electric Cloud and Gwyn Fisher, CTO of Klocwork together for a candid discussion of the cost savings, productivity and quality benefits that can be achieved by stabilizing builds and code quality as early in the development cycle as possible.
Register Now!

Collabnet -TeamForge 5.3
CollabNet TeamForge 5.3 includes Dynamic Planning—providing flexibility to model release scope and timeline in a single view. Now, you can easily manipulate/adjust release data.
Download Your Free Trial

Requirements-based testing (RBT) can help to ensure comprehensive test coverage, reducing the risk of failure and improving software quality. This white paper details how application lifecycle management can be used to more effectively implement RBT processes, offering greater collaboration, traceability and control.can help you increase efficiency, reduce project risk, and improve overall software quality. Learn how MKS Integrity for application lifecycle management enables RBT, delivering full lifecycle traceability to help ensure that project requirements have complete test planning and execution coverage.
Download the Requirements-Based Testing whitepaper

PureCM –SCM for Agile Teams
PureCM helps you to manage development in short iterations: keeping track of changes, supporting automated builds and preserving frequent snapshots of your projects.
Get the free trial now