Revolutionary Agile Project Management with RTC

[DISCLAIMER: I have NO monetary relationship with IBM or any of its subsidiaries.]

If you develop any serious software, I'm sure you're tired of manual steps required to collaborate among the various tools involved in the process of Agile software development. You need to take a hard look at IBM's Rational Team Concert (RTC) for its ability to facilitate collaboration among the multitude of tools development shops use for managing requirements, stories, code, builds, tests, deployments, issues, defects and all of the various threads that run through a large software development effort. Hint: RTC has legendary Eclipse pedigree.

I've been using RTC for about a month now and strongly recommend it as a solid option for truly end-to-end Agile software development. You may be familiar with other Agile Project Management (APM) tools such as Rally. I've used Rally extensively and it's a good product. RTC, however, is in a league of its own. It has no real competitor. (Poor man alternatives include Redmine, Trac, Pivotal Tracker, TargetProcess, Skinnyboard, VersionOne, GreenHopper and Agilefant, likely with at least a few bandaids and serious gaps in each case. Read on to find out why.)

RTC is fundamentally a tool for APM (stories, tasks, estimates, burndown, velocity). To that extent its functional matrix can perhaps be tallied against a top notch product like Rally. RTC offers three client options. One, an Eclipse-based rich client. Two, a Visual Studio-based rich client. And, three, a Web 2.0-style web interface. The Eclipse client is very intuitive for developers already familiar with Eclipse. (Don't all developers use Eclipse?)

RTC allows team members to enter their percent allocations to the project as well as any scheduled absence dates. It then calculates each team member's available capacity in hours. Stories, estimated in days, can optionally be placed into a hierarchy of features, requirements, stories, and tasks. RTC's extreme flexibility comes at a cost. For instance, the unwary user can easily trip over herself and define a hierarchy of stories (i.e. a story with another story as its parent -- not recommended). Once stories have been broken down into tasks and tasks have been estimated in hours, RTC will tally up and graphically display a comparison of each user's allocation and capacity in hours. This allows the team to determine which team members are over-allocated and vice-verse. As work gets completed, users update the effort remaining on their tasks and this is reflected in the hourly burndown chart, which is one among many canned reports available in RTC.

RTC is endlessly customizable and organizations can either pick from one of the templates (Scrum, Eclipse Way, OpenUp/RUP, Cloudburst, SimpleTeam) or define their own template, as my organization has done since we estimate stories in terms of a range of aggressive/low and conservative/high estimates. Templates control a number of process aspects such as the number of iterations per release, roles, permissions, and workflow (pre-conditions, post-conditions).

I do have a few nits with RTC.

• The release burndown chart, where you see story points completed, does not display a target reference for stakeholders to know how the actual story point burndown is measuring up against the target or minimum required to keep the project on track. Calculating per iteration velocity targets also requires knowledge of per iteration staffing levels, which RTC does not currently store. Therefore, any measurement RTC provides on actual versus expected story points is based on assumption of a resource allocation model that is uniform across iterations. However, again RTC's flexibility might offer a solution since it is apparently easy to add attributes and create new reports and dashboards (I have not tried this yet).
• The facility for entering absences is awesome. However, IBM should look into integrating with calendar applications such as their own Lotus Notes, Microsoft's Outlook and Google Calendar. Furthermore, statutory holidays should need to be entered just once and then show up as default entries on each team member's list of absences. A team member who is planning to work the holiday can delete the default entry. (Thanks to Neil Roy for reminding me about this nit.)

But the comparison with APM tools like Rally ends here. RTC has much more to offer. This solution, built on top of the familiar and highly popular Eclipse platform, is leaps and bounds ahead of the competition because of its out-of-the-box integration with all phases of the software development process including (and more to come):

• Application Lifecycle Management (Mylyn, Tasktop)
  
• Requirements Management (Requirements Composer)
• Version Control (ClearCase, Subversion, CVS, Git)
  
• Code Review (CodeCollaborator)
  
• Build Automation (Ant, Maven)
• Continuous Integration (Build Forge, Hudson, CruiseControl, TeamCity, RTC's Native Jazz Build Engine)
• Test Management (HP Quality Center, Quality Manager)
• Defect tracking (Bugzilla)
• Issues Management (JIRA)
• Workflow Automation (ClearQuest)
• Collaboration (Sametime, GTalk, Jabber)
  

That's not to suggest that all of the above-mentioned integrations are seamless. For example, RTC implements a third-generation version control system (streams, atomic change sets, branching, merging, and Subversion-inspired blame) on top of whatever native system you use for version control (see above). But if your native version control system is not 3G you will clearly have to put in some imperfect workarounds. For instance, see this discussion on RTC integration with TeamCity.

Describing the entire feature set is beyond the scope of this article. I will, however, list a couple of features that really grabbed my attention.

• RTC offers a team debug session feature wherein a debug session can be transferred to another team member via a link in an instant message or email. Cool, huh?
• The tool contains several canned reports. And users can build their own. But I prefer to use the ability to write adhoc queries to answer questions such as: "Which team members haven't entered their task burndown in several days?"
• RTC revolves around the workitem paradigm. Workitems can be capabilities, functions, features, requirements/epics, use cases, stories, tasks, risks, away stories/dependencies, builds, issues, defects, retrospectives, and action items. Workitems are the threads that help to tie it all together into a unified view of the Agile software development project landscape. (Organizations can enhance RTC by adding their own custom workitem types.)
  

Furthermore, thanks to its pedigree (Eclipse), RTC is highly extensible and can integrate with tools written in any programming language that has the ability to communicate over the Internet.

In addition to items mentioned above, the following are just a few more examples of some of the less obvious kinds of elements that are customizable in RTC.

• Workitems (add enumerations to existing attributes, add new attributes)
• Dashboard (a collection of canned and custom portlets in the Web UI)
• Different teams can following different processes (see above for process template)
• Process templates can be localized/translated into multiple languages to support globally distributed project teams
  

And just to be clear (since I've seen a lot of confusion on this elsewhere), RTC is NOT a replacement for any of your existing systems and tools. Instead, think of it as a dashboard and a tool of tools that helps you orchestrate all of the tools used during the software development lifecycle in a typical Agile shop.

As you can tell, it's a pretty large and ambitious system and does, therefore, involve a bit of a steep learning curve to get all of it completely under your belt. But there is no reason to eat the elephant in one big gulp. One easy bite (or feature) at a time is the way to go. And thankfully, RTC's many features do not have to be used in an all-or-nothing fashion.

The product is FREE for up to 10 developers. And truly Agile teams ought not to be any larger! The free, entry-level edition (also known as Express-C) ships with the Tomcat application server and the Derby database embedded into a single package. If you're lazy (like most good developers are), you can conduct an easy evaluation of RTC's capabilities simply by connecting your favorite browser or rich client (Eclipse or Visual Studio) to IBM's hosted sandbox.

If you've been following the news, you know that revolution is in the air. And RTC is a welcome addition to that revolutionary spirit -- a one stop shop for managing your stories, code, builds, tests, defects, issues and more!