David Ross's Blog Random thoughts of a coder

A common theme within my posts is how Iteration and Feedback is the life blood of an agile project.  A project consists of a repeating series of sprints.  Sprints consist of goals/user stories to be implemented.  Within each sprint there are planning sessions, retrospectives and milestones/tasks.  Tasks in turn can be designed/implemented using a Test Driven Development or Acceptance Driven Development approach which are often described using the Red, Green, Green analogy.

• Red - Create a test to flesh out the public interface/the expected output of the component
• Green - Develop code that implements the public interface and fixes the test
• Green - Refactor the code so that it is simpler or more maintainable

Its clear that there are iterations within iterations within iterations.  In this regard Agile projects are fractal like in nature with the entire SDLC consisting of self similar behaviour across the time axis.  Recently I have found it useful to generalise each of the iterations (no matter what level of abstraction we are dealing with) to the following:

• Envisage
• Innovate
• Stabilise

Envisage (Analysis hat)

verb: This is similar to imagine; it means to form a mental picture of something which may one day exist.

The Envisage phase is primarily concerned with asking the following questions:

• What is the project/sprint/goal/milestone/user story/component trying to achieve?
• How will be different post iteration?
• What is the success criteria for completing the iteration?
• Are there any edge cases that need to be investigated?

Phase is being performed incorrectly when:

• More time is spent discussing the solution's implementation as opposed to problem definition
• Only the Happy Path is analysed
• Tests are written that make assumptions about the implementation

Innovate (Creative hat)

verb: to introduce something new; make changes in anything established. (www.Dictionary.com)

I have purposely chosen the word innovate over implement or build to describe this phase.  Being innovative implies that we can experiment, prototype, flesh out and most importantly make mistakes.  Its concerned with:

• Solving the indentified problem
• Plumbing and Infrastructure

Phase is being performed incorrectly when: 

• More time is spent getting to Green than finding new edge conditions
• More time is spent Refactoring than writing new code
• More time is spent working on plumbing than solving the identfied issue

Once the problem has been solved its time to switch focus to strengthening the quality of the solution.  This entails:

• Writing more tests
• Refactoring
• Ensuring that all edge conditions are accounted for 
• Change/Risk reduction

  Phase is being performed incorrectly when: 

• New tasks are continually being found (implies team is still in Innovate stage)
• Changes are introducing bugs
• Features are being added
  

Conclusion

By generalising all Iterations to Envisage -> Innovate -> Stabilise its becomes very easy to determine what type of activity should be performed.  For example I only allow infrastructure or plumbing changes to occur early in a sprint so that there is ample time for stabilisation.