Iteration is a strategy for discovering a requirement by building software and soliciting feedback. By travelling through this cycle a few times you home in on the true customer need. Where there is a high degree of complexity of uncertainty this feedback driven approach is likely to be more cost effective that attempting to completely analyse the requirement.

By contrast an incremental approach involves building a part of a solution completely followed by the next part.

While iteration expects re-work and assumes the requirement is not known, incrementing can be used when the requirement is well understood and does not pre-suppose (or rule-out) re-work.

In practice we should seek to combine iteration and increments. In previous posts I have described MMFs (minimum marketable features) as a strategy for defining increments. Iteration can be used within each increment to ensure that the customer need is met.

To complicate our mental model a little we can iterate across increments. This provides us with the opportunity to respond to feedback from the market in addition to feedback from more immediately accessible customer representatives.

It is critical to think about iteration when planning a project. While some stories will pass through a single development cycles others may take 2,3 or 4 iterations in order to deliver the value they represent. A simple velocity measure does not provide for the uncertainty and variation that this can represent.

Now for the theory

The Cynefin framework developed by David Snowden described 4 different problem domains; in fact there were 5 and I’ll only consider the first 3 right now.

The domains relate to where we might choose to use iteration.

Simple – sense, categorise, respond
Simple problems are characterised by simple cause effect. When faced with problems in the simple domain we should find out the current best practice for the problem and apply the solution.

Complicated – sense, analyse, respond
Complicated problems are the domain of the expert. With sufficient expertise and thought these problems can be broken down into their simple constituent parts.

Complex – probe, sense, respond
Complex problems are different. These cannot be broken down into simple problems or solved by hard thinking. Rather we must solve these problems through experimentation and feedback.

As we seek to understand our customers needs we should consider where they fit in this classification. We waste our time if we try to analyse complex requirements. By contrast if rely in iteration for simple or complicated problems we are likely to take longer than necessary.

The best teams will learn to recognise where iteration is most valuable and where to apply analysis.

• Be rigorous with terms and definitions: Tom described that, in his experience, careful definition of terms will increase your ability to use objectives to justify decisions. This is particularly true where a document must stand alone.
• Break down objectives so that they can be represented using a single scale: we had objectives that required multiple scales such as combining schedule adherence and quality; Tom recommended a hierarchical model.

An example of one of our objectives is:

Objective: Teams are efficiently delivering high quality, high value software at the right time
Ambition
Team’s clients recognise the quality delivered and appreciate the timeliness of delivery and ability to respond. Clients see their needs met and the benefit realised through deliveries.
Scale

1. % of deliveries that meet client expectations
2. Ratio of value delivered to cost
3. % reduction in cost of delays incurred (£/week) by project teams
4. Mean satisfaction level (0-10) of project sponsors

Having identified a set of objectives we began to brainstorm the strategies, i.e. approaches we could take, to achieve our objectives. We started our with a minimal expression of strategies e.g. “Coach teams”. As we began to evaluate the impact of the strategy against the objectives we found we had to be far more specific. This included identifying how many people would be affected, what areas the coach would focus on.

By adapting our approach to the needs of the teams or organisations we coach, we can recognise where instruction is appropriate and where we are better served by using a coaching position.

Often the challenge we face is the ease of simply providing an answer when compared with the challenge of working through a issue with a coaching stance. A coach will typically seek to raise awareness and convey a feeling of responsibility for a situation and subsequent actions. By contrast consultants often fall into the trap of building dependence on their own expertise by not releasing responsibility.

Where a consultant is considered critical to a team this can be indicative of taking the easy route and providing answers rather than seeking to coach individuals thus building confidence in the team.

The first speaker was Kent Beck talking about test driven development and a concept that he termed software health. As a software engineer first and formost I am particularly interest in any approach that claims to improve quality. Kent was claiming more that this.

The term software health covered, in addition to quality, attributes such as flexibility to change, resiliance against regression and maintainability.

The second speaker was Mary Poppendiek. This was my first exposure to “Lean” thinking. Lean seems to me to underpin agile. Lean is a set of guiding principles that originated in the late 1970′s in the development of the Toyota Production System. Since then the same ideas have been rolled into many manufacturing businesses and also other areas such as logistics. Mary has taken these ideals and applied a software spin. After hearing what Mary had to say I went and bought her book and would recommend it to anyone interested in agile.