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



He then scaled complexity and uncertainty on a scale of 1 to 10 and plotted them. The results look a lot like the Boston matrix with 4 quadrants Stars, Cash Cows, Dogs, and Question Marks covering market share and market growth. This leads to what Todd names the Houston Matrix with 4 quadrants defined as follows:

1. Bulls: Process defined to cope with complexity, need agility to handle uncertainty.

2. Cows: Complex mature market, need defined interfaces

3. Skunks/dogs: High uncertainty really small

4. Colts: Simple young projects need agility and tight teams

Todd concludes that products tend to follow a life cycle path: the most successful start out as skunks or dogs, move to colts, become bulls then cows and eventually dwindle down back to dogs. Others just move from dogs to colts and back to dogs. Projects that start out as bulls do not end up doing too well.

Todd then defines some of the core activities his team adapted:

1. Aggregate product plan: what are we about, why are we doing this and why is it important

2. Abc list (priority list like MoSCoW): a – guaranteed, b-likely, c-might. Only a are committed and no more than 50% of planned effort can be a. At the end, all a’s, some b’s and a few c’s are delivered as well as some d’s which are new requirements.

3. Quality agreement similar to Thomsett . Mark categories as very important, important, not very important. Categories included: Completeness of functionality, completeness of testing, reliability, performance, installation, usability, integration, on line help, training

4. Continuous integration

5. Expert user involvement

6. Project dashboard

Next Todd moves to the Business side and talks about the Business Process Chain Value and cover 3 types of businesses:
Product Company: Market -> Product Development -> Sales -> and loop back to Market (does not fit with CMMI)
Contract Model: Specification -> Development -> Delivery (hand off with no feedback loop) (fits with CMMI)
Internal IT: Business need -> Development -> Delivery -> have option and should have feedback loop back to business need

Todd discusses portfolio management and dealing with Darwin (Moore). This time the axis are mission critical and market differentiation and the 4 quadrants are:

1. Invent when there is high market differentiation and low mission criticality (create change, ad hoc)

2. Deploy when there is high market differentiation and high mission criticality (embrace change, agile)

3. Manage when there is low market differentiation and high mission criticality (control change, structured)

4. Offload when there is low market differentiation and low mission criticality (eliminate change, outsource)

Finally, Todd discusses individuals and team dynamics by addressing security and value in terms of Tribal leadership from the book Great Boss Dead Boss by Ray Immelman. The idea is that the team is the tribe and they have to deal with issues like individual security and tribal security. When dealing with security:

1. High tribal security, and high individual security results in complacency, process focus (rules and regulation become important), and no risk or innovation.

2. Low tribal security and high individual security results in cooperative effort to strengthen tribe, personal sacrifice, and a common enemy.

3. Low tribal security, and low individual security results in everyone leaving the tribe, individuals laying claim to valuables, and searching for new tribes to join.

4. High tribal security, and low individual security results in resignation from the tribe, the tribe ejecting individuals, and individuals act to harm tribe.

Similarly for value:

1. High tribal value, and high individual value results in strong support and encouragements, individual heroics praised, high motivation, extreme loyalty.

2. High tribal value, and high individual value results in urgency to change, individuals honing their skills, symbols reaffirmed, relationships reviewed and improved.

3. low tribal value, and low individual value results in finger pointing, involving outsiders, promoting own world view, in fighting.

4. High tribal value, and low individual value results in feeling out of step with tribe and forming a new tribe.

Todd wraps up by stating that for tribal leadership, focus on increasing individual security, individual value, and tribal value. Do not make the tribe too secure. And this is a never ending goal.

This presentation is available on InfoQ at http://www.infoq.com/presentations/choosing-agile-methodology