Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

Lean tools: Iterations

04.11.2012
| 4569 views |
  • submit to reddit
Mary Poppendieck points out three principles of iterations:
  • short iterations force small batches, where features move quickly through the system. It's not necessary to wait a six-month release to deploy a new feature.
  • They keep options open: in the first ones, the feature set is not frozen but is allowed to respond to feedback from the customer.
  • They provide, at their end, a point of synchronization with the customer and external people or teams.

Iteration planning

The description of iterations in Lean Software Development follow what is specified also by other Agile methodologies:
  • iterations have a duration of 1 to 4 weeks.
  • Features are modelled as user stories that can only be developed in a single iteration: they have to be splitted when too big to fit.

The estimation of which features can be implemented in the current iteration is performed by the team, which commits to a subset of stories. New features or changes to the existing ones have to wait the end of the current iteration, delaying feedback to a standard point in time. You can't pester a team by changing their priorities every day.

The end product of an iteration should be running and releasable: features have to be tested, integrated and deployed on a internal server.

An expression of feedback

Iteration are a feedback-based tool. After several ones, you'll know how difficult is the testing, integration and deployment part: these phases cannot wait the end of the project, as they are a source of risk that has to be reduced.

Moreover, you could get a measurement like the velocity of the team, along with a rough estimate of the number of iterations needed for a further set of stories.

However, there are incremental methodologies that take batch sizes up to hundreds of features, like the Rational Unified Process. Feedback that comes too late and in too large quantity is not as useful as rapid, bite-size feedback on a couple of stories. In fact, the ideal batch size is probably one...

Open source project example

In PHPUnit_Selenium, I am using patch-level releases as iterations, although I can't timebox them due to the lack of fixed available time.

For example, Selenium 2 API support is a large feature that has been divided in:

  • basic: finding elements, a few accessors on the session like the title of the current page.
  • Element manipulation, and accessors for their attributes.
  • Window and frame changes of focus, and resizing or movement.
  • History movements: back, forward, and refresh buttons.
  • Timeouts configuration.
  • Cookie setup and removal.

From the 1.2.0 to the 1.2.6 releases, one or more of these features have been included. I don't mean to say that you should release the product of each iteration, only that you should theoretically be able to do that.

The principles at work in breaking this large feature were:

  • small batches: the first examples of support have been actually out for 2-3 months instead of being released now that the whole feature is more or less finished.
  • Options: if no one cared about Selenium2 support, I wouldn't have developed more mini-features (I kind of pretotyped the support.)
  • Synchronization: developers can try the new features at each release and open issues related to a few focused elements. I wouldn't want them to use PHPUnit_Selenium from the master branch, which is updated every day, as the bug or missing pieces they will encounter would be a source of tickets.
Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)