The Pitch

As technology workers and managers we often have more things to do than we have time, so we are constantly on the lookout for time savers. They say that time is money and we all know that to make money you have to spend money. A similar concept applies to time in that you have to spend time to save time. We'll look at how JIRA helps you do this, but also focus on how to implement JIRA to make sure it's a success.

Specific topics will include:

• Who should get a JIRA project
• Setting realistic expectations
• How usage will differ between types of users
• Using JIRA to Get Things Done

In the Beginning

I was first introduced to JIRA when Chico got involved with uPortal. The transition from Bugzilla had just happened and the system was a bit new to everybody. I decided that I needed a local solution to track issues in my own projects and being the frugal employee that I am, I looked to the open source offerings. After many failed starts, I installed a trial version of JIRA. I was off and running and eventually sold my boss on buying an Enterprise license, mainly because it had LDAP functionality, which is pretty much required for us with most things.

At first it was used exclusively for my department (two people) and we used it how software developers typically use these kinds of systems. After I was more comfortable with the system I gave a presentation that was open to all of Information Resources (central IT). A few groups were interested and I gave out projects like candy on Halloween because I was just excited that people wanted to use it. But...

Pragmatic use of JIRA has two flavors:

1. How JIRA can be deployed for effective use in your organization
2. How JIRA can be used on a project by project basis.

What Not To Do

Pitch and Ditch

1. Create project
2. Provision users
3. Send login URL to project lead
4. Watch project not get used

A shockingly large percentage of the early projects I created for people were abandoned after a week, sometimes less. You can't effectively use JIRA to track issues if you aren't using JIRA.

Oversell Customization

Because I was so eager to get people into JIRA I would always push how customizable it was. This immediately put most folks on the wrong path. They started thinking about how they would turn JIRA into the "ultimate workflow." This was code for "lets make JIRA do our work for us." Oddly enough, this is something that JIRA is incredibly poor at doing.

For folks new to JIRA projects, set an amount of time where they just use the default set of issue types, screens, and workflows. After they have used the system and understand where it could be changed to improve their usage you can go in and start creating custom screen with custom fields all wrapped up in a custom workflow. The default set of features are very useful right out of the box and a lot of folks will adapt to it and stick with it.

What To Do

Talk to Potential Users

This concept really came from how we launched our Confluence pilot, which so far has been very successful, and it's where you can (try to) set realistic expectations. We now ask folks that are interested in getting a project a set of standard questions.

1. What problem is a JIRA project going to solve?
2. Who do you envision using JIRA within your organization?
3. How would you use JIRA within your organization?
4. What other solutions have you tried?

If JIRA is introduced as a mandate without any discussion about how it will be used, the chances of it being a success are slim to none. While you are working with the project lead to avoid unnecessary customization, it would be wise to also take that time to impress upon them how important it is to explain to the team how JIRA is supposed to solve a problem.

When you are explaining the internals of JIRA it's good to focus on how most of the features are semantic in nature and the users define what they mean. For instance, you can close or resolve an issue. What's the difference? Well, it can mean what you want it to mean. For our group we took the de facto standard of "closed" to represent that it wasn't an issue and nothing was done, while resolved meant that we did work and that is why the issue went away. Another group on campus decided that technical folks would resolve issues and the leads would go through and verify the work and then close the issue. Again, you define how you want JIRA to work for you because JIRA is good at showing you issues with specific characteristics. Depending on your license you can create more status values and increase the complexity of the workflow. Be careful about doing this, for down this road lay dragons.

Successful usage also depends on the project lead and the team all being on the same page about what the system is for and how it is going to be used. Of course, at first they may not know exactly and this is where you need to help them keep it simple by avoiding customization (at first).

Customizing

I know, I know...don't oversell customization. Well, customizing a project is something you still want to avoid if you can. But showing a user how to customize their JIRA interface is well worth your time. At first, people may not like JIRA. If you give them a way where they are in control of what they see, they will dislike it less.

Follow-ups

Check in with your project leads. Make sure they have what they need and that JIRA isn't presenting any technical issues that are preventing them from using the system.

Create a filter to watch the activity of the system. Put a charting report on your dashboard. Anything that helps you get a read on the usage of the system. If the system isn't getting used, you need to figure out why.

JIRA Basics (What To Do, Part II)

In addition to being very effective at tracking issues, JIRA has really facilitated communication when it has been used in cross-departmental situations. It's superior to e-mail because it's centrally located and easier to search. Teams all across campus can be involved with an issue, share comments, attachments, and screen shots. The open nature of the system can be disorientating at first.

Permissions

This is an area that can get out of control very, very quickly. Do all that you can to avoid this! People will want to keep this information as private as possible. They'll consider it "dirty laundry" that nobody else outside of their small group should ever see. Try and convince them otherwise. Information transparency across departments is very valuable.

Roles

The addition of Roles to the newer versions of JIRA will help reduce the load on administrators having to tweak permission schemes buy allowing project leads to add users or groups to roles that are already in their scheme. We haven't done much with Roles yet, but we envision moving to them exclusively for new projects and then migrating existing projects.

Groups

We've gone with the standard of departmental groups.

csuc-DEPT-admin (read, write, delete+admin)
csuc-DEPT-user (read, write)
csuc-DEPT-guest (read)

All users get put into jira-users automatically and need to stay in this group if you want them to be able to login.

Moving Forward

As people want to expand permissions lead them in the direction of thinking about roles and not people. "I want Bob to do this and Alice to do that" is not really where you want to go. If you keep schemes as generic as possible it will be much easier on you when they come back for another project, as you will just be able to apply their permission scheme to the new project and be on your merry way.

Notifications

When a new area is going to get a project, try starting them out with the default notification scheme. It's very chatty. There is a risk that verbosity will give people a bad first impression of JIRA, but ideally it will also prompt discussion in the group as to how everyone would like to use the system. The project leader would need to emphasize that during the initial ramp-up (typically where pre-existing issues are imported) there will be more notifications than there normally would be. Notifications could also be set to none during the initial import if this was going to be a big issue with the team.

We created a minimal scheme that only sent e-mail when issues on created/assigned and closed/resolved. I should note that this works well for my department because the two of us share and office. A minimal scheme would ideally include a notification for comments as well.

Components

Components are the puzzle pieces of your project. Often you will see people new to JIRA wanting to make projects out of components.

Versions

When you talk to people who aren't tracking software issues you need to sell this concept as a milestone. It's simply a target in the future that will help JIRA build the road map you need to take with your issues.

Uses of JIRA at Chico

PeopleSoft (CMS) 8.9 Upgrade

Our CMS effort is split across many functional groups, with just as many competing philosophies on how to track issues. Functional meetings often consisted of trying to merge spreadsheets. This was not fun.

Enterprise Systems

New to the system.

Human Resources

"JIRA is my brain." CMS function team was first in and was more than happy to get rid of their spreadsheets. It's slowly moved to "regular" HR.

WebCT Vista Support

Working across departments. Communication between project leaders needs to be established first. Vista is an effort that touches almost all areas of Information Resources:

• sysadmins
• DBAs
• the portal
• Network Operations
• the faculty
• student help desks
• functional Vista folks.

Working with Non-participating Departments

Assign the issues to yourself. You're keeping track of when they are done anyway.