(The iteration demo)

Jim Shore has put up yet another text from his upcoming book ("The Art of Agile Development") for review on his blog. This time he talks about the iteration demo: A live demonstration of what has been accomplished during the last iteration, that can be attended by anyone that is interested. Jim describes the demo as a "way to keep the momentum going" and lists three purposes to the iteration demo: (1) Demonstrating progress, (2) keeping the team honest about progress and (3) soliciting feedback from interested parties and stakeholders.

I feel that an essential benefit of the iteration demo is how it portrays progress and instills the feeling of momentum in the team. Agile development can actually suffer from the way progress is flows in tiny increments, making it difficult for developers to perceive the speed and momentum of the progress. This may make the team feel that there is little momentum and that little happens - since everything evolves so incrementally. It's like when you watch some slow movement, such as watching clouds on a calm day, trying to discern what direction they are moving in with no fixed reference point: It is not immediately apparent.

However, to someone outside the project, the progress made over one week is obvious, since (presumably) a great deal has happened since the last reference point (the last review of the product). Again, if one were to mount a camera at the sky and take pictures at longer intervals, movement would be immediately obvious.

When an outside stakeholder reviews progress, there is commonly a strong positive reaction - "wow, all of this has been created since last time? Cool!" When developers see this emotion, it is "transferred" to them - they effectively experience the feeling of momentum and progress via the reviewers of the demonstration.

The negative effect of *not* perceiving progress and the momentum of a project is great - a project that is taking great strides forward feels successful, and causes team members to be substantially more productive. The iteration demo is a device that allows a team to get that valuable feeling and productivity.

I was pleased to notice that so many had not had the opportunity to get up to speed on continuous integration before our talk yesterday. Of all the people in the auditorium only 2-3 felt they knew what all the "hoopla" is about.

Even though we could have used the full fifty minute slot, I think that we managed to cover the essence - although there is so much more there in the form of experiences and perspectives to talk about.

As promised here is the presentation slidedeck. Since it was so heavy on images I have made them smaller, although this download is still large (6mb).

Links to good articles - the web is naturally full of both good and bad, but don't miss these:

• "Continuous integration", good article by Martin Fowler.
  There is actually a new and an old version.
  
• "The agile difference for SCM" Very nice agile overview with SCM focus by Appleton et al.
  
• From some XP summaries by Don Wells (this one has some links to interesting discussions on c2 wiki) and Ron Jeffries
• "Continuous Integration – just another buzzword?", nice overview by Appleton et al
• "Codeline Merging and Locking: Continuous Updates and Two-Phased Commits" , good info on 2-p commit pattern (Brad Appleton, Steve Konieczka, Steve Berczuk, same gang as above)
• "Agile SCM - Build Management for an agile team"

On the conference:
We had a great time at Developer Summit 2006 in Kista, Stockholm. I applaud all the great guys and gals at Cornerstone for managing to create such a cozy gathering!

The first day started out with an interesting overview of mashups and the semantic web. Erik did a great top 10 developer donts kind of thing that I enjoyed very much - highlighting best practices, many of which are reexposed in agile. After lunch, Jimmy did TDD and we got a nice agile progression going upto my CI talk. The second day highlights for me was probably Manges entertaining causerie on Web 2.0 and an entertaining overview of open source development in .NET by Mats Helander. Patrik did WF and Johan a potpourri of coming VS.NET stuff.


Lets hope we get the same kind of event next year. For more conference and development fun this year, keep your eye on Öredev scheduled for November.

If you are migrating to VS.NET 2005 and converting projects, the VS.NET conversion wizard will do that for you. Then you can use MSBee to compile into both 1.1 and 2.0 assemblies.

 

However, if you are migrating the build process perhaps before all projects in your organization have migrated, people will still be developing in VS.NET 2003 for some time, yet you want to have a standardized build process, around MSBuild.

 

This little MSBuild task will convert a VS.NET 2003 project on the fly so that you can use MSBuild to compile it.

 

Pretty niche scenario, yet since I found myself there, others probably will too.

 

It is easy to use, you just slap a Using element and then use the task, giving it the projects name. Thats it. Installation is xcopy. The readme gives step-by-step instructions. Happy building!

ConvertTo2005.zip (10.87 KB)

Agile methods focus on the people issues in developing software; the people perspective of the open source movement - ie the community - is often the perspective that is most emphasized and cherised, for good reason. People are always the focus, technology is secondary.

Rob Mensching at microsoft (who is behind MS open source - CPL - licensed WIX installer toolkit) has a very nice post about the people part of OSS.

Are all of the agile practices so new?