Blogs about Jazz

Blogs > Jazz Team Blog >

The smoothest end game ever… but why?

Tags: ,

About a month ago, my wife, who has lived through 20 years of software deliveries with me at IBM, turned to me and asked “Aren’t you guys shipping Rational Team Concert real soon now?  You don’t seem nearly stressed out enough – is it still happening?”  I assured her that we were still shipping on time, but that, for some reason, this was the smoothest delivery I had ever experienced.

Talking to other PMC and development team members, I observed how well the end-game was going, and got universal agreement.  No one had been involved in anything that shipped this easily, which is even more amazing given the complexity and importance of the Rational Team Concert 1.0 release.  So I followed up asking “Why is it so easy this time?”

In hallway conversations, on PMC calls, over beers at the Rational Software Development Conference, and in team retrospectives, here are some of the explanations we heard.

“The plan just worked, we shut down major feature development early, and (excepting licensing and install) most teams were in bug-fix mode by M6.”  OK, that works.  There’s a report available now which shows bugs Closed by Iteration, and it shows fixing ramping down exactly as we hoped.  M6 was the last big spike, and each subsequent iteration came close to our goal of reducing fixing by half.


“Self-hosting did it.  Rational Team Concert is ready to ship because our self-hosting has forced it to be good.”  Definitely agree with this one.  In fact, from now on, I only want to work on software that has the unfair advantage of self-hosting.

“The process rules enacted for the end-game, requiring reviews and approvals, made it happen.”  As we entered the end-game, we turned on process rules that required approvals for fixes to be delivered.  Any code delivery had to be associated with a work item which had an attached approval.  Each iteration in the end-game, we increased the required approvals and reviews.  In RC5 and RC6, we required two code reviews, a team lead approval, and two PMC approvals.  The two PMC approvals seemed to work especially well, as it enabled a “good cop/bad cop” approach where needed, with a single PMC “no” vetoing a fix.  After a few of these, the team understood we were serious about evaluating the risk/reward of any code changes.

“The whole project had visibility to what was going on, and was able to adjust course to make sure we succeeded.”  In the end-game, the PMC actively developed the Jazz Development dashboard to promote this shared awareness.  Tabs devoted to candidate bugs gave a view at a glance at what was being targeted and checked off progress.  Burndown charts showed that the brakes were working and the code was settling down.  Erich says “Making things visible is the first step to make things happen.”



And, finally: “We’re just way better and smarter than we’ve ever been…”  OK, Kevin and I made that one up…

Scott Rich
Jazz Foundation Lead