JIRA, Confluence, and Stash Ride Motorcycles – Agile for Bikers

Agile for Motorcycles?

It is no surprise I love to ride motorcycles.  I’ve been riding with my current group for going on three years.   Some time ago the tech chair approached me about using a issue tracker to manage the club business.  I laughed.  We were a motorcycle club!   After becoming president, three years of managing Atlassian products, and becoming an Atlassian I very much agreed with him.  We needed a better solution for managing our affairs.  As a motorcycle club, one might ask: why do we need JIRA and Confluence?

We have a lot of the same problems that surround collaboration but is also exacerbated by the fact that we have long periods of time where we aren’t physically together.    We started out with 4-5 riders that have now expanded to a band of 40 with another 40 who are potential members.  With a board of 10 spanning everything from president, to technology, to ride captain, membership, treasurer, etc we have a lot of people to keep on the same page.

We’d tried a number of tools in the past that just didn’t quite work for us.

• Meetup didn’t have the means to collaborate on things.  Meetup was great for publishing out final plans and getting our club name out.  It didn’t do well when we needed to discuss and plan.
• Google Docs was great in that it was integrated with Google Apps, but we found the access control to be hard to use.  Google docs didn’t track changes over time so it was tough to see change.
• We had a hard limit of 50 users with Google Apps.  After that it got too expensive.
• We didn’t entertain Microsoft office and email for any length of time.

Last year I was traveling somewhat and took the opportunity to dial into three of our meetings.  Since I didn’t have near as many as visual cues, it gave me a better understanding as to how the meeting runs.  We had some improvements we could make there: clear agenda, better transitions between conversations, and smoother way to handle in meeting feedback and action items.

Also,  I wanted a better way to handle the time between meetings.  Because we didn’t have much face time between meetings we spent a fair amount of time in the meeting getting everyone back on the same page.  We only meet monthly.  In a 2 hour meeting, we spent an hour “catching up”.    With 10-15 people in attendance, that was a lot of energy.  We needed to walk into that meeting prepared: clearly knowing what to say and what was up elsewhere in the club.

With 10 people on the board it was hard to know who was doing what at any given time.  I tried using email but it had one major drawback: I was the task master.  As a fully volunteer club, I need to rely on people’s good will vs telling them what to do.  I wanted to use accountability to the group as the driver to get stuff done instead of having to pester people.

Enabling The Software

As a product marketing manager for JIRA I felt it was a good thing to remain an active JIRA admin so that I retained my connection to being a customer.  What I didn’t know is that Atlassian has a community license program for non profit organizations like ours.  Any open source or non profit organization can apply for a community license of Atlassian products.  The Atlassian community licenses are for the download versions of the products.  The first task was figuring out where to host the products.  We installed them on a Linux server in our data center (re: the garage).

We wound up using a service called DynDns.  DynDns is a dynamic DNS service that we can use to bind a host name to that server.  Since we are only hosting one virtual host on that server we can also use SSL without a static IP as well.  We fronted all of the Atlassian products using a simple instance of Apache that proxies for the various Tomcat containers.  Depending on the size of your organization and number of concurrent users, you don’t need a ton of hardware to make this work.  System memory is the key here.  We’ve got 16G but 8G would have been fine.  We only have 2-3 concurrent users at any given moment.

With everything running what did we need to do?  The next step was configuration.  I needed to outline what problems needed solving, what technology was going to be used to solve them, and why that technology made things better.

Working in the nonprofit space in this respect really isn’t any different than any for-profit company.  I needed to prove to the membership that this solution was going to be better and worth the cost of transition. In the next post I’ll outline how things are set up in JIRA, Confluence, and Stash.