Don't forget to iterate!

In the 1964 case Jacobellis v. Ohio, Justice Potter Stewart wrote that hard core pornography was hard to define, but that he'd know it when see saw it.

This also applies to product development. It's hard to define what you want, as people have a hard time envisioning the future. When someone actually has something tangible they can make better decisions about what they want. i.e. they know what they want when they see it.

One of the reasons why agile software development works is by shortening the feedback loop and adjusting a project based on the things that have been learnt over it's lifetime. This can be done in a couple of ways. Firstly by doing incremental development and secondly by doing iterative development. Unfortunately many Scrum teams focus on the former and forget about the latter. Incremental development it easy to understand and is baked into the Scrum cycle. It's expected that at the end of a sprint that we have a 'potentially shipable product increment'. I believe that this wording is partially responsible for creating a misunderstanding that we should only be incrementing.

One anti-pattern I've seen is when a team tries to develop an entire feature in a story so that they have their potentially shipable product increment. This feature is complete as far as they're concerned so they can then proceed to the next story and do the same. These stories then only get reviewed by the Product Owner (PO) in the sprint review meeting. Though there's a much shortened feedback loop compared with traditional software development projects, we've lost some of the learning. We shouldn't just learning about what features need to be developed, we should also be learning about how a feature is developed. This is where iterative development comes in. We need to getting something into the hands of the PO as quickly as possible so that they can see if it's really what they want.

I recommend doing the following:

1) Treat each feature like an experiment. Build a hypothesis about what you're trying to achieve then go about proving or disproving it.

2) Slice your feature into stories as thinly as possible. Start with the simplest possible implementation of the feature. Put things such as safety or experience factors into subsequent stories.

3) Shorten the feedback cycle. Talk to your PO throughout the sprint. Show them as the feature evolves and gather feedback. Some of this feedback will generate more stories. Others will allow us to make smaller course corrections. We're continually learning.  Also remember that your PO is meant to be a partner in this effort, a collaborator.

4) Deploy each completed story into a staging environment so that the PO or trusted end users can start playing with it. Remember that just because a story is of a potentially shipable quality, it doesn't mean it can be shipped. That decision is up to the PO.

To sum it all up, don't forget to iterate!