Convert from Fogbugz to JIRA - case study

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.

The Problem

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

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.

The Story

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.

Transition Day

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.

Post Experience

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.