I was in Asia last month setting up an Agile process for a large systems integrator. We customized an RTC process template and a set of RMC practices in parallel. Our goal was to enact much of the RMC published process in RTC, creating RTC tasks each iteration that trace back to the process description. We built an environment where team members can create work items and get support in performing that work by linking directly back to the published process.
In today’s blog I’m describing some tips that will make your life easier when you set up your own process enactment integration between RMC and RTC. These tips are based on real-world issues and pitfalls that you’ll want to avoid. This is an implementation of the RTC/RMC integration I wrote about earlier.
We also did some neat stuff like creating a work item template that generates a user story work item and the tasks needed to support writing that user story. Said another way, we enacted (in RTC) the User Story practice that’s described in RMC. The customer uses this work item template whenever they identify a new user story, significantly improving the chance that they will perform the tasks necessary to successfully complete the user story, and giving themselves detailed information and guidance on writing user stories.
The work item template includes a combination of RTC defined work items (user story) and RMC defined work items (tasks) in a parent-child relationship. I’ll describe how to create this kind of work item in a future blog.
And now for the RMC/RTC integration tips.
Tip #1: Always Be Aware that You’re Working with Task Descriptors
The RMC/RTC integration is a clever and useful way to enact your RMC process, but it can be a little brittle. If you aren’t aware of task descriptors and GUIDs, you can end up with broken links in your RTC work items.
When RMC publishes a process, it uses a Globally Unique Identifier (GUID) to create the name of each HTML page. Each process element has its own internal GUID that is used to create the HTML page, guaranteeing that each page name is unique.
When you export tasks that will be used in an RTC work item template, the GUID goes along with the export. But you aren’t really exporting tasks. You’re exporting task descriptors, which is what shows up in the RMC Work Breakdown Structure. Task descriptors are essentially copies of tasks, and those copies are what show up in the work breakdown structure of your delivery process. This allows you to use the same task in many different places in your process, which is a good thing. But it can lead to confusion for process engineers who think that they’re looking at a task when they’re really looking at a task descriptor.
Like every other element in RMC, the task descriptor has its own GUID. Of course, this GUID is different from the task’s GUID. This is fine, until you delete or replace task descriptors in RMC that have already been exported. Now that you’re using different task descriptors than what you exported, you get different GUIDs for the task descriptors. Different GUIDs means different HTML file names in the published process. Different file names means that the link embedded in an RTC task that points back to the published process will be broken, because the task descriptors that were originally exported have different GUIDs than the ones that were published. So always be aware that when you delete or replace a task descriptor that has been exported, you’re breaking the work item template that was imported into RTC.
Tip #2: Put Task Descriptors inside Capability Patterns
So how do we avoid removing a task descriptor once we’ve placed it into a delivery process? We place them in capability patterns (CP), and only use CPs in our delivery process. This is a good practice to do anyway – it keeps your process more modular. But it becomes even more important when you’re enacting an RMC process in RTC. You can delete CPs from a work breakdown structure in a DP (or from other CPs), but that won’t delete the CP from the library. So your task descriptor (and its GUID) are preserved.
Start by creating CPs that only contain tightly coupled tasks. Some CPs might have a single task in them (that’s OK), but you’ll probably find that you have tightly coupled tasks that can safely be included together in a single CP. That is, keep tasks together that will almost inevitably be performed as a group. Such as:
- Outline User Story
- Detail User Story
- Plan Iteration
- Manage Itearation
- Assess Iteration
Placing these together in a single CP will give you a WBS to export the tasks from, and protect you from having to delete/replace the task descriptors (which would force you to re-export them and replace the original work item template in RTC). Build the rest of your CPs and DP from these atomic CPs. When you drop one of these atomic CPs onto another CP or a DP, change the Activity Type to an Activity, Iteration, or Phase.
Tip 3: Publish When You Export
Every time you export task descriptors, you’re probably sending new GUIDs to RTC in the form of work item templates. If you don’t publish as part of exporting, you risk getting the work item templates and the published process out-of-sync. If they’re out-of-sync, you’ll have broken links in the work items you create in RTC.
It’s probably best to publish first, deploy to your web server, validate your changes are included, then immediately export any new task descriptors. Make this a single operation and you’ll stay out of trouble.
Tip 4: Automatically create tasks when an RTC project is instantiated
Work item templates exist in two places in an RTC process template. You can include them in the Links section, which is where work item templates are kept when you import tasks from RMC. This allows you to create tasks by selecting Create Tasks from Work Item Template in the web interface’s Work Items dropdown menu.
The other place you see work item templates is in the Process Configuration tab, under the Project Configuration/Project Area Initialization section. These work item templates are used to create work items when the template is instantiated as a project. This is where you want to add tasks that will always be performed just once in the project, such as:
- Plan Project
- Setup Environment
- Create Vision
These templates must be entered by hand. You can replicate the look and feel of the tasks that are exported from RMC by exporting as normal, then copying the HTML that’s encoded in the exported XML file.
Add a hand-written work item template that links to your published process by going to the process template, open Project Configuration then Process Area Initialization. Under Server Followup Actions, select Setup Projet. Under Work Item Templates on the right, select the New Template button.
Use the HTML option, and copy the task name, description, task steps, and link into the work item template. Here you can see some examples of hand-built work item templates for RMC tasks created from examples exported from RMC. Both tasks are defined in practices shipped with RMC
Tip 5: You Only Need to Export when you Create or Delete Task Descriptors
As described above, you need to be aware of the state of the task descriptors that you export (new, deleted, etc), and keep these in-sync with published process. On the other hand, you can make changes to anything else in the process and publish/deploy the website without fear that links will be broken. This includes modifying tasks and synchronizing task descriptors. Neither of these actions will break links or cause problems.
This means that you only need to export task descriptors to RTC when you create new ones. You will want to delete and replace any work item templates that include deleted task descriptors. And to be complete, you should also delete the XML export file that includes deleted task descriptors.
Stay aware of these tips and they’ll keep you out of trouble when maintaining the integration between RTC and RMC. And if you have any tips of your own for the RTC/RMC integration, please add them to the comments section!