Friday, February 15, 2008

Context Driven Agile Leadership- Managing Complexity and Uncertainty

Todd Little gave a talk at Agile 2006 about context driven agile leadership. He starts out by comparing agile planning to hurricane prediction. Predictions are made within a cone of uncertainty. It is a forward looking view towards uncertainty. We know generally where we are going, but we are not going to a point, we are steering towards a general direction. As we move forward we adapt and steer towards the market.

Todd mentions that his work was influenced by Jim Highsmith’s adaptive software development, Alistair Cockburn’s crystal methods, and Boehm and Turner’s Balancing Agility and discipline.

Todd briefly discusses the Crystal Method matrix covering number of people involved (1 – 1000) vs. Criticality (Comfort, Discretionary Money, Essential Money, Life). A crystal method (clear, yellow, orange, red) is selected based on project size, system criticality, team priorities (productivity, tolerance, legal liability). Todd notes the crystal clear does not scale into larger teams and does not go upwards towards essential money.

He then discusses how Boehm and Turner took crystal’s 2 dimensions of criticality and number of people involved and made 5 dimensions by adding personnel experience, dynamism (# of requirement changing per month or uncertainty), and culture (preference to structure and order). They observed that neither agile nor planned provide a silver bullet. They each have home grounds where each clearly dominates. Future development will need both agility and discipline and some balanced methods are emerging. It is better to build your method up then to tailor it down and methods are important, but potential silver bullets are more likely to be found in areas dealing with people, values, communications, and expectation management

Todd takes a closer look at the right side of the Agile Manifesto (tools, documentation, contracts, plans) and mentions that the tools should enhance collaboration environment like wikis, documentation should be a consumable rather than a deliverable, contracts should be written in a manner that are consistent with collaboration and agile delivery, and plans should expect and anticipate change.

Todd explains how he evaluated projects based on
1. Complexity: team size, mission criticality, team location, team capacity (novice vs. expert), domain knowledge, dependencies

2. Uncertainty: Market Uncertainty (known vs. new and untested), Technical Uncertainty (enhancement using existing technology vs. new architecture and new technology), Project Duration, # of people dependent on us