Convert from Fogbugz to JIRA - case study
Updated: Dec 3, 2018
The ARANZ Geo ( now Seequent) Story - the right time for change
ARANZ Geo is one of Christchurch's fastest growing and successful software companies. But its pace of growth was becoming impeded by its out-dated internal information/communication systems - bug tracking, QA systems, task management, status tracking.
Venduco architected and implemented a JIRA solution that resulted in improved workflows, and with zero down time for the AranzGeo staff.
With high demand for product updates and new features, the development manager, John Good and his team of 20 developers, had evolved a highly effective software development process - for the size of company it was.
But now ARANZ Geo was growing.
ARANZ Geo already knew, based on customer feedback, that they were releasing high quality software on schedule. They intended to keep it that way.
This is the point at which John Good, development manager at ARANZ Geo, called in Venduco Ltd.
John knew that one pinch point restricting growth was the information systems the whole team used to manage their day to day work. These systems - custom reports and dashboards custom written on top of a Fogbugz bug tracking system were old, expensive to upgrade, and could not configured to handle growth and additional teams.
Utilizing the Power of Short Queues
The key process to ARANZ Geo team efficiency had been the use of Kanban to track and control the size of all input queues - bugs, features and technical debt. Very conscious of process, they had built custom dashboards that enabled them to monitor all critical queues. The dev manager groomed the lists that appeared on the reports. Devs used the same reports to find their personal todo lists If any queue became too long, the dev manager could immediately readjust what was on the todo list.
Through my career, I have been part of many development teams and ARANZ Geo's process was one of the most time-effective I have seen. Keeping todo lists continually groomed reduced the need for the meetings I dread: "bug scrub" meetings. It also eliminated the need for discussions on priority - only 2 priorities were ever needed - urgent and normal.
The team was colocated so face to face discussions resolved most communication issues among developers, testers and Business Analysts. This all resulted in good morale and low stress levels, which supported constructive, collaborative problem solving - exactly what is needed to build complex, quality software on time.
The challenge John laid out for me was to preserve the software process they had so carefully evolved, and to replace all the tools everyone was using daily - bug tracking, dashboards, custom reports and to do so with zero down time for the team.
My first few days on the job were spent talking to developers - everyone was super helpful - being a process oriented group, everyone on the team was keen to have better tools to improve their process. To understand how people really worked, I documented processes which were known by all, but up to that point, undocumented. I created a glossary to understand the meaning of words: bug, feature, project, product, team, release date, etc.
Using this, I created, as you do, a plan and schedule estimate. I estimated 35 days of my time. Then I got to work.
Decision 1: Stick with Atlassian
I have worked with JIRA in several companies. Years ago, I had selected this product because it is configurable, scalable, cost-effective, well supported, has an ecosystem of products that interface with it, it's reliable and is constantly being improved. It was an easy decision to go with JIRA. ARANZ Geo selected the Cloud version to save staff time maintaining a hosted version. Security and reliability of Cloud version was good. The downside was many useful add-ons were only available on the hosted version. (hopefully this will change in future). We also utilised the integrated Confluence Cloud version for both storing documents. At the same time, I brought in Hipchat. The purpose of Hipchat is to replace email conversations. Hipchat preserves a history of conversations. I set up all the dashboards in Confluence, not JIRA, to get better formatting control and to support embedded Confluence pages.
Decision 2: Create new paradigm based on actual practice
The biggest challenge in the transition was "no down time". This meant that everyone, starting on day 1, would have to understand how the new dashboards, bug tracking system, reports and technical communication worked. To me, this meant KISS - keep it simple. I knew the design and workflow of the new system must be sketchable on a whiteboard or a short slide set - there mus t be one common view of the process. The glossary was helpful when talking to people to understand exactly what they were meaning. The design was the trickiest part and was the result of many conversations between John Good and myself. The paradigm of course would have to fit into the JIRA ruleset . We arrived at several simple rules:
Each JIRA project mapped to exactly one repo.The people in the ARANZ Geo development team were in any one of several groups - ( and they could change groups at any time).Each group had its own view into JIRA - some groups needed only to view one repo ( JIRA project), some were working on parts of various repos.All information in the system and repos was visible to everyone in the ARANZ Geo dev team.The group views of the repos were controlled by JIRA filters leveraging JQL.We did not need to change all the tools to Atlassian after the transition - in fact, it was wiser to minimise the risk and only convert those tools we needed. We would continue with Mercurial, Zendesk and TeamCity. Our original plan had been to put source control in BitBucket.
Decision 3: Import all bug history or not
The next few weeks I spent building prototype Information systems using Atlassian JIRA (Kanban), Confluence and Hipchat. One decision was how much of the "past" history should we bring along with us. We decided to bring along all the Fogbugz bugs, importing with the JIRA tool, since the JIRA import process worked very well and there was no reason to exclude any history. However we decided to not bring all the Mercurial source code history in Mercurial, in order to keep the repo size smaller. The complete historical repo of course was kept in archive if needed.
Multiple test imports resulted in 63 manual steps that needed to be done after the automated import to ensure every bug was migrated perfectly. Part of the ambiguity was matching the old concept of Fogbugz milestones to JIRA releases. These 63 steps were documented so they could be repeated on the Transition Day.
Decision 4: Source repos
We originally planned to move source to the cloud - Bitbucket. Before the transition, we were not happy with the authentication available at the time with Bitbucket. ( Atlassian has moved to address these issues in the meantime) so instead maintained source in its current repos. This required additional engineering. We are looking forward to the Bitbucket updates in this area.
Decision 5: Training
From the beginning I talked with as many developers as possible about how they worked. As we came closer to the transition day, I met with all the teams for an hour each, to work through the test systems I had set up. I took the feedback and tweaked the workflows. I set up a small group as my personal advisers - this team would take over JIRA workflow and design decisions after I left. I documented the new workflows, new screens and glossary in Confluence.
We selected the weekend to do the transition. Developers landed their branches by Friday. Friday 6pm the old system was shut down. I began the import of all the Fogbugz tickets into JIRA ( it ran overnight). I watched the import carefully and after several restarts it was ready on Saturday AM. John, myself and Bryan Morgan, senior developer then got to work, following the 63 steps in the Fogbugz->JIRA transition plan, and resetting the build processes and grooming all the test cases, comparing the JIRA version to the Fogbugz original. New dashboards were set up with production data. By Sunday all was ready and the JIRA/Confluence system was ready for production.
The Day 1 Experience
On Monday, everyone came to work as usual. I came in at 9am, wondering what strangeness developers had found on their brand new screens. A couple of people came over to me to ask some questions. All was quiet as folks looked at their new dashboards and new formats through the morning. By noon, everyone was hard at work. I answered some more questions. Tuesday I went home due to lack of work. My part of the project was over, exactly on the 35 days I estimated.
2 months later I came back to follow up with John, eager to learn what things I had missed in the transition. They had made no changes. The releases had all gone smoothly. The new paradigm was no problem.