Blogs about Jazz

Blogs > Jazz Team Blog >

Some notes on rhythm

I’ve been a software developer for about 14 years and been involved with too many projects where the schedules shifted and slipped – frustrating the developers and losing the interest of customers.

So it was an epiphany to me several years ago to see the way the Eclipse project used “rhythm” to get great output from a large group of developers at a consistent pace. I wasn’t sure what “rhythm” meant at first in the context of software development but as I soaked up more and more of the Eclipse Way process I’ve come to think of it like this:

  • daily rhythm – daily build and test runs, and of course writing code
  • weekly rhythm – cross team integration and weekly builds
  • “milestone” rhythm – 6-8 week rollout of features and fixes in stable releases
  • yearly rhythm – a major release that satisfies even the most conservative adopters

One thing I really like about Jazz is the way an infrastructure for sensing rhythm has been built-in and surfaces in a lot of useful places, large and small, in Rational Team Concert. For instance plans can be created at each iteration level you define in your process. (For Jazz we define yearly and milestone level iterations and a type of sub-milestone level iteration that I’ll mention below). Here’s a look at the top of the Plan editor:


Note how the label (“0.6 M5D1”) and dates of the iteration this plan describes are shown along with an indication of the team’s progress through the iteration.

I could add more screenshots showing how project rhythm surfaces in Rational Team Concert, but I’ll save space and let you explore for them. Look at how milestone iterations show up in the Work Item editor and in the Team Artifacts view for instance.

But I would be remiss to not mention that rhythm in Jazz flows from the way you define and customize your process. The Jazz process specification is the “conductor” for a project’s rhythm as shown here in the Project Area editor:


Note that “rhythm” is defined in terms of a project’s iteration structure. In the image above each top-level node is a development-line which has an independent iteration structure. So the rhythm of maintenance may be different from the rhythm of mainline development, which matches our real-world experience.

You may be curious what “D1” means (as in M4D1 and M5D1) in the screenshots above. In the course of developing Jazz we have found that a mid-milestone re-deployment of the Jazz Team Server we use (based on changes made so far in the milestone) helps to keep us on track – so D means “deployment”.

The general point is that having a flexible process definition infrastructure allows for projects to more easily find a rhythm that fits their needs, and we have been taking advantage of this flexibility as we develop Jazz.

Chris Daly
Jazz Component Development Team