We have 3989 guests and 1 member online

Video Spotlight

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

The Agility Cycle - Part 2

 E-mail
Written by Brad Appleton   
Friday, 17 April 2009 09:19

We saw in the previous blog-entry several definitions of the Business Agility Cycle. We also mentioned that in order to derive the Software Agility Cycle from this, we needed to explicitly include more close collaboration.

The Software Agility Cycle is:
  • Sense the Problem/Opportunity
  • See the Problem in the Context of the "Whole"
  • Socialize the Goals and Constraints
  • Swarm the Solution
  • Show the Results
  • Share the Knowledge Learned

Here's how I derived the above... Once again, I'll refer to Jim Highsmith to represent the "people and collaboration" component of software agility.

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.

The other problem with the business agility cycle is that it seems to presume that decision-making about what solution to attempt is done by a smaller, separate group of people than those who will implement and deliver the solution, and we merely need to communicate to them and have them act to execute the solution.

It's not clear whether this assumes knowledge or design of the solution "up front" with a "handover" to an implementation team, or whether it can mean that determining the solution needs to be just as collaborative as its implementation and must involve many of the same people, all working together at the same time.

The collaborative aspect of software agility demands that the solution emerges from those who must create and deliver it, and that they are empowered to make the decisions about what that solution is and how best to do it. Rather than having the decision made for them and simply "executed" by them, once the problem became known, the request or opportunity would be presented to them as a problem to be solved, together.

The goals and objectives would be socialized, along with the needs and constraints, and then those who must collaborate across the value-stream to devise and deliver a solution would get together to make it a reality. They would learn what they needed to know, show results to customers and stakeholders and then get feedback to try and learn and adapt.

This yields a slightly different cycle for software agility than the one we had for business agility:
  • Sense the Problem/Opportunity using whatever local feedback mechanisms have been put in place to become aware of it. This is the same as it was in the business agility cycle.

  • See the Problem in the Context of the "Whole" system. Rather than "strategizing" this is more like the "orient" step from Boyd, or the "interpret & evaluate" step from Oosterhout. This lets us properly frame the problem within the organization and its "delivery system."

  • Socialize the Goals and Constraints among all those who will work together to devise and deliver the result. This is similar to the communicate step from Gartner, but we didn't really decide what the solution should be. We decided what to do (the vision) at a high-level but not the details of "how." We haven't made a detailed plan or spec.

  • Swarm the Solution, collaborating intensely and self-organizing as needed across functions, organizational and geographical boundaries, etc. This combines the "act" and "decide" steps into a single, self-organizing group responsible for the result. We delegated the decision-making authority to them about what exactly to build and how to go about building it.

  • Show the Results, demonstrating the knowledge gained about the solution in "executable" form so we can get feedback as to its validity. Then finally ...

  • Share the Knowledge Learned with the rest of the organization so they can inspect, adapt, and move forward. And most importantly so they can remember how they learned what they now know.
The thing to remember is that this cycle happens at every level of scale in our delivery system. If we do this cycle once for a large problem, we have ourselves a waterfall. The above cycle applies to ALL the feedback loops that need to be put into place. There is the delivery-cycle, the release-cycle, the planning-cycle (the timebox), the development-cycle (backlog-item), the integration-cycle (e.g., TDD and CI), and the peer-review cycle (e.g., pair programming). They all go thru these same six steps in some form or another:
  • Sense & See (sense locally, see globally)
  • Socialize & Swarm (socialize the problem, swarm the solution)
  • Show & Share (show the results, share the knowledge)
These are the steps of the software agility cycle that we use to Evaluate change, Collaborate together, Validate the results, and then Iterate over the cycle again, applying our newly found knowledge to learn and adapt was we go.
The Agility Cycle - Part 2

Posted: 2009-04-17 17:19: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