Update: After reading this entry, Erich asked me to point at that Eclipse/Jazz didn't invent the idea of the demo push; he believes that we picked up this practice many years ago from Scrum.
Next week is the Rational Software Developer's Conference (RSDC) and it should surprise no one that there will be some Jazz news and a demo of Jazz technology. A couple of weeks ago I pointed folks at video of a presentation John Wiegand and Erich Gamma gave at JavaOne, talking about the agile software development practices that the Eclipse organization has adopted over the years. One valuable practice that I've vividly experienced the last week is the demo push.
A basic idea in iterative development is that at regular (preferably short) intervals, you produce a working system with some subset of the final features of the planned release. A trick to make this more real and more tangible to developers is to find some venue where you can demo your new version of the software at the end of the interval. The rules are simple - demonstrate an interesting set of scenarios that cut across the system and fake as little as possible. The requirement to produce working code by a hard deadline is a powerful motivating factor that helps drive issues to closure by starkly constraining the 'time' leg of the resource triangle. Also, if your iteration's work isn't in the demo, it feels like you didn't really deliver anything, which is a very bad feeling in a culture where the ultimate measure of success is delivering working, high-quality software.
Example. A fellow Jazz developer and I have some functionality that is closely related, but for various reasons hadn't come together as well as we would have liked by the end of the current iteration. On Thursday of last week I had a call with Erich to review my Jazz web UI team's status for the RSDC demo. I told him that I wasn't confident that the two components would be integrated but that I had a back-up plan to simulate integrated components. Typical of Erich, he wasn't interested in the easy way, he was interested in the right way, so he politely said "we should use the RSDC demo as an opportunity to drive these issues to closure, so I want you to work together to really integrate your components by the RSDC demo". Result? The components now work together - not perfectly - but they are loosely integrated. But the most important part of the exercise is that we've each learned a helluva lot about each others' components, we now understand how they can integrate, and we have a list of technical and process issues that we need to tackle in the next iteration.
So using a publicly visible demo is useful not just for showing off fancy new features, but also to drive tough issues to closure. This sort of environment - the peer pressure to do the right thing even though it might be difficult - is one of the things that makes me feel grateful to work in this organization.
PS - I won't be at RSDC next week. My wife and I are at t-minus one month for Higgins baby #2 (this time a girl!), so I'm staying close to home. That and my manager Scott forgot to put me on the list. I wonder if his forgetfulness has anything to do with the awesome April Fools Day joke I played on him a few months back? More on that later...
the demo push