Moving and Consolidating: Ticketing

Continuing on with our Moving and Consolidating, today we're going to cover our process of choosing a ticketing system. We've already covered code hosting in a previous post.

Criteria

• Integration with source control (specifically GitHub)
• Support for multiple projects
• Fine-grained access controls
• Agile tools (scrum-style sprint planning)

This wasn't an exclusive list, nor was it really a list of hard requirements.  We were willing to accept a system that was missing some of the features if it excelled in areas we get more value.

Starting Point

We started by using Redmine. On the surface it met all of our needs but in practice it was found wanting.  To be fair, some of these shortcomings may have stemmed from a lack of attention in setup, maintenance and updating.  Regardless of the reason it was our assessment that it was time for a change.

One caveat: We are still using Redmine for some of our older projects.  They will eventually be transitioned.

The Search

There are a lot of ticketing options out there.  They range from startlingly simple to confusingly aimless.  A few weeks were spent evaluating and experimenting. We ended up settling on two candidates: entp's Lighthouse and Atlassian's JIRA.

Lighthouse

Lighthouse is sold as "beautifully simple" issue tracking.  It provides a few simple and well-executed features. Ticket entry is quick and easy.  You can organize your tickets into milestones and tie things into your GitHub projects.

We often found ourselves frustrated with Lighthouse, however. While it delivered what it promised, we repeatedly bumped up against difficulties:

• Stability: Lighthouse was unavailable quite a few times during our work day
• Markdown: We were really spoiled by GitHub's markdown rendering
• Almost Enough: The "simple" approach didn't implement quite enough for us

That last bullet warrants some explanation.  Many on our team were used to more featured systems and we seemed to be running into the edge of Lighthouse's features quite often.  We should've written up a summary at the time so that we could cite specific examples.  Having made this change months ago, they have escaped me.

JIRA

JIRA was always in the running because a few of our team had considerable experience with it.  We hesitated becasue there is a considerable cost involved.  While JIRA is certainly worth that price to many organizations, it was worthwhile to try the competition's offerings before we settled on paying the premium.

It should be noted that Atlassian has recently revamped their hosted offerings. In our opinion the previous "Studio" product was many steps behind the equivalent downloadable offerings and too expensive to boot.  The new OnDemand product is much better and we applaud Atlassian's decision to revamp the line.

To JIRA

Moving to JIRA involved a few perl scripts and a few days of shuffling. Since we opted for the download versions, we had to stand up a new server to run things.  JIRA is memory hungry and I recommend that you run it on a machine that has at least 1.5G of RAM.  This is laughable for real hardware, but an expense to consider if you are using VMs.

We obviously make heavy use of JIRA's projects.  Some of the deeper features such as versions and components have been a bit slower in adoption.  We are, however, refining our procedures and getting people up to speed.

The biggest problem we've had is that JIRA ships with a very austere default dashboard.  Users are often paralyzed when they log in for the first time because there is no obvious call to action.  This can be helped by setting a different default dashboard for your users, but this is difficult when your users are working on wildly different things.

We solved some of the adoption issues by setting up screen sharing calls (using the join.me service with great results) where we walked through JIRA's features and showed people how to use them.  This was very successful and many users reported being really happy with JIRA after this.

Not All Rainbows and Unicorns

Atlassian has proven to be a worthy steward for your development needs.  Each new release provides a mix of fixes and new features that improve your experience.  Looking back over the years I am happy with their progress.  They may be a bit slower than your average OSS project, but they also have a real customer base and a large organization.  Their work is commendable.

Summary

There is a fine line when choosing new tools.  Users will complain quite loudly about new features, but it's very difficult to find the time to solicit feedback from everyone about a new tool.  Finding the time to allocate toward product evaluation for a useful number of people is challenging, especially in a consultancy.  If you have someone who can put themselves in your user's shoes and make a recommendation, that's your best bet.

Many of our projects have adopted custom workflows that reduce the work our developers and management have to perform. Once you teach your users what JIRA is capable of they begin to ask great questions and suggest improvements. This change has resulted in a much more organized and efficient organization.