It's not an Iteration if you Only do it Once!

The title of Jeff Patton's conference talk was: Embrace Uncertainty, Why in Agile Development Knowing what you want may be an Impediment to Getting it.

I came into this presentation about 20 minutes in because I ditched my first choice conference due to irrelevant content with respect to my likings. I'll get more into the details of my general feelings towards the Agile 2008 conference and its enormous amount of topics in a later post.

What left the biggest impression in my mind when I stepped in was the following quote which I used as the title of this post: "It's not an Iteration if you Only do it Once!"

I found this to be quite revealing because I sometimes find that we forget what iterative and incremental development is over time and slowly fall back into the dreaded waterfall model without even knowing it. Lets take a look at what gets us into this pattern and try to find some strategies to get out of it.

The following should sound familiar: "That iteration stuff is good but we have commitments to keep...". Software is often a line item in a larger plan. Failing to release on time may put the bigger plan at risk. In order to properly plan we need to properly estimate and with estimation comes uncertainty.

Jeff proposed 3 strategies themed with musical clips to help us cope with this uncertainty.

1. Follow the Money

• Follow the user stories back to their source
  

User stories build software, software is used by user constituents and all this to satisfy one or many business goals. The purpose of this strategy is to start at the business goals and work your way down to eliminate parts of the user constituents and reduce the overall set of user stories. This helps you focus you development by selecting the stories that are related to business goal which have high business value.

2. Don't choose your solution too early

• Firstly write user stories that describe what people want to do
• Defer selection of which user stories to implement to later
  

This bit might sound a little confusing but I'll update this section later with a link to the presentation which explains this principle using a diagram.

3. Build up feature quality iteration by iteration

I found this section to be VERY RELEVANT. The following is a heuristic for slicing up quality goals:

• Necessity
• Flexibility
• Safety
• Comfort, Luxury, Performance
  

This list represents the categories for quality goals. The idea is to start by implementing goal that are necessities and working your way down to the comfort and luxury items over iterations. This basically mean that instead of fully developing a feature withing a single iteration, the feature itself should be divided in tasks that will implement a different level of quality goal per iteration. For example, you are building a text editor:

• Iteration 1: You build and implement basic text editing capabilities such as creating a file, saving a file and editing text. (Necessity)
• Iteration 2: You provide a mechanism that allows basic style such as font selection, bold typeface and italic typeface. (Flexibility)
• Iteration 3: You implement unit testing beef up the code of the basic features to make it more robust. (Safety)
• Iteration 4: You add some bells and whistles to make the application's visual style appealing and optimize the memory required. (Luxury)
  

This above example might not be perfect but I think the idea gets across.

Finally, let me know if you need some clarifications on this information for I have miss a small part of this talk. I'll be glad to provide more information once I receive a copy of the presentation from Jeff.