Within Jama, we pride ourselves on “drinking our own champagne” — using Jama to build Jama. It’s a rare occurrence in software development that you get to design and build the very product that is core to how you work, one that makes your everyday tasks more pleasurable. Our product development organization uses Jama to manage our requirements, capture product and design decisions, and flesh out product ideas and build backlogs. The communication and collaboration features in Jama are key to keeping our engineering organization aligned with the product and business departments.
While we all work in Jama, our engineering teams use an agile scrum methodology and their day-to-day sprint planning and execution is managed in JIRA. Core to our workflow is the seamless synchronization between Jama and JIRA. We’ve used our original JIRA connector for this purpose, but when we launched the Jama Integration Hub, based on the Tasktop Sync product, a far superior tool, it naturally became a priority for engineering to make the switch.
Rolling out the Jama Integrations Hub at Jama
When we launched this initiative there was much to learn about the Integrations Hub and how it fit into our agile workflow at Jama, so we decided to take an incremental approach to the change. We have a number of scrum teams so we set out to migrate them one at a time over a course of a few sprints, allowing us to incorporate learnings from each migration and refine the process and our usage of the Integrations Hub. The nice thing about the process of switching to the new Hub is that you can migrate your teams and workflow away from our original connector incrementally, so the two tools can work side-by-side until all teams are completely migrated over to the new Hub.
We started out by engaging with one of our own implementation consultants, Matt Mickle, to learn about the Hub and the migration best practices. We mapped out our own agile development workflow, and the Jama- and JIRA-specific workflows that would be integrated. We created a timeline and created documentation that we would refine as we discovered more best practices for our specific needs. We also set up a migration support team and escalation process in the event we ran into any issues post-migration.
With this important up-front planning we knew what a migration looked like, how long it would take and how it would affect the capacity of the team during the migration process. In a truly agile way we had enough to start our incremental approach.
What we learned in setting up the Jama Integrations Hub
After we started the first team migration to the Integrations Hub we discovered a few issues which we quickly resolved, and then added new efficiencies to the migration process (more on that below). We also quickly learned that if we wanted to take full advantage of the Integrations Hub’s templates we needed to clean up our existing JIRA workflows. Up to this point, we didn’t have a consistent JIRA workflow, nor a naming convention. Remedying this problem as part of the migration process had the added benefit of establishing consistency across our teams and actually made our own JIRA administration much easier. Once we cleaned up our JIRA workflows we were able to take advantage of the Integrations Hub’s templates, adding a Story Template and a Defect Template, which gave us huge efficiencies. Now migrating a project, or even setting up a new project, is a matter of simply creating mappings from our existing templates.
Another lesson we quickly learned was the timing of all the various steps involved in migration. Our goal was to have a streamlined process for migrating teams to the Integrations Hub with little downtime. We determined that we could creating the Jama and JIRA filters needed for the Integrations Hub’s mappings the day before the migration, saving time waiting for a schema refresh. Huge amount of time saved!
Our next challenge was scaling the migrations and administration of migrated teams in the Integrations Hub. We already had a few tips from Matt Mickle about consistent naming of mappings in the Hub. We came up with a naming convention that incorporated the team name, item type, and the type of mapping. That way we could just simply look at the mapping names to know what they were instead of having to open them up to see what they were mapping and which team they belonged to.
A better workflow makes for a better product
Today we have all the scrum teams in engineering migrated over to the Integrations Hub. We have a well-documented Hub set-up process and naming conventions. Our JIRA workflow for migrated projects is now consistent across teams, which we found actually improved our Jama workflow, too.
We also understand the Integrations Hub a lot better now and can take advantage of all the new features with each release from Tasktop. For example, the ability to scope mappings by project, introduced in the Jama Integrations Hub 4.3, is a very useful feature and allows for more flexibility in how we structure projects in Jama.
The biggest win for our team, though, is that now that we now that we have integrated our Jama and JIRA workflows we have better insights into our product development process via a transparent workflow from product requirements through test results. Moreover, the integration of the data from each tool allows us to seamlessly jump into each system without paying the tax regularly associated with switching between tools, losing context, and waiting for data to synchronize across systems. This is a big time saver for our engineering teams and makes it seem like a single interconnected workflow instead of separate systems that we’re using.
Tips for a successful migration to the Jama Integrations Hub
- Map out your end-to-end development workflow. While we use JIRA, the Hub also integrates with Version One, Rally, and Team Foundation Server. Include in your mapping how your development tool workflow meets your Jama workflow.
- Utilize Integration Hub templates. The Hub’s templates are a huge time saver and ensure a consistent process.
- Use consistent naming in your filters and mappings. This makes managing several teams and mappings much easier and allows you to scale your integrations with your development tool.
- Make your development tool workflow consistent. Once we did this we found it was much easier to scale our integration and actually helped bring more order and consistency to our own JIRA workflows across teams.
- Document your migration procedure. We created a checklist to ensure a repeatable and consistent process which could be improved over time.
- Create your filters ahead of the migration. By creating the needed filters for the Integrations Hub mapping the day before the migration and then refreshing the Jama and JIRA schemas within the Hub, it made our actual migration process much faster.
- Work with your Jama Customer Success team. For us, inside of Jama, this meant having someone from consulting and support available to assist. For you as a customer, we recommend working with your Jama Customer Success team to quickly deal with any issues as they come up. Once you’re through the first few migrations the process will get faster and easier.
Our team would be interested to hear from you about how you’re managing workflows between teams, whether you’re using Jama or not yet using Jama. Do you have integrations between the various tools that your business, product and engineering teams use?