Tag: admin

So, you’ve just been handed a box and told “This is yours now.” Or maybe you just landed your first job as a JIRA Admin. And maybe you start to feel that panic when you realize you don’t even know where to begin…

First, take a deep breath, everything will be alright. You got this. In the words of Douglas Adams:

This week we are going to focus on what you should do leading up to and during your first week as a JIRA Admin, with an eye on setting yourself up for future success.

The Lead up

Okay, so I know some of you don’t get this luxury. As I stated earlier, you didn’t know you were about to be a JIRA Admin. You just got handed a box and told “Here you go” with no further preamble or instructions. If this is you, you can go ahead to the next section. However, if you are fortunate enough to have interviewed for the position, this is for you.

I typically start during the actual interview for the job. While a job interview is still about convincing the hiring manager that you are right for a job, it is also as much about seeing if the job is right for you. As standard operating procedure, I always have a list of questions printed out to ask. For a JIRA Admin role, they often look like:

• Is your instance cloud, server, or data center?
• If Server: Is your instance bare metal or on a VM?
• How many teams and users does it support?
• How many projects and issues are on it?
• What is your governing policies around JIRA?
• What is the state of your end-user documentation on how to use JIRA?
• What Apps (plugins) do you run?
• Am I replacing another JIRA Admin?
• Will I be the only JIRA Admin on staff?
• What is your biggest pain point with your current JIRA usage?

As you can see, these are questions designed to get to the heart of what your first tasks should be coming into an organization, by gauging where an organization is with it’s JIRA instance, and what problem spots there could be.

Don’t sit on this information though. If you get the position, the answers to these questions can help you do some research before you start that will give you a head start on day one. If there biggest pain point is JIRA is slow, you can research on causes of lag in JIRA and have a plan ready to diagnose and resolve them. Or if their biggest pain point is no one has visibility into anything anyone is doing, you can have some end-user docs on JQL searching and Dashboards prepared to copy/paste into their Knowledge Base (cough cough Confluence cough). The goal is if you have some warning, take the time to become prepared.

You’re First week

Day One

So, you’re sitting in front of your computer. You’ve finished all the HR stuff, tours, introductions, and general pageantry that always goes with a first day on the job. Now what?

I’m going to be honest, some of this is going to assume a few things. First, that you are the only JIRA Admin that is managing the instances you are working with. Second, that things have not been managed otherwise. Sometimes you get lucky and these are not the case. More often than not though, this is what you will be walking into.

First thing you should do is take stock. Check that you have admin rights to every application you are managing. Make sure you can get into every node of every system under your management. That includes back-end systems like databases and file shares. If those systems are managed by another department, make sure you get introduced to an actual person who can help you with those systems. And for the love of all that is good, if there are no documents for all of this, take your time and write some for every system.

Second thing I do day one is start to figure out who is actually using the instance. Start with the following JQL search:

ORDER BY updated DESC

This will give you the issues with the most recent modifications within your instance. Take note of what projects these issues belong to, and who is making these modifications. This will give you an idea of who is using the instance actively. Depending on how the information is flowing, you might be able to see evidence of bulk edits going on. Take note of who is doing this – as anyone knowledgeable enough to do a bulk edit is likely a power user, and someone you want on your side.

If you have time, find out what teams are using the active projects and make plans to meet with those teams this week. If they are active within JIRA, they may have insight into pain points that Management might not be aware of. This will also show that you are an admin that cares about who they are and how well they can do their work – and you cannot pay for that kind of goodwill.

Day Two

Day two is about taking control. Figure out who else has admin rights on your instance. Do they require admin rights? If no, how politically sensitive is it going to be to take those rights away? In an ideal world, only people on your team would have admin rights. You shouldn’t depend on being the only Admin (unless you absolutely love being called while on Vacation), but everyone shouldn’t be an admin on the same time. I find giving the team you are working on Admin access is usually a good balance there.

However, we don’t live in an ideal world. Unless you happen to be a VP, it’s going to be politically difficult to tell another VP that you are taking away their admin rights. However, here is a trick. Figure out what exactly they were doing that required the elevated access. Is this something reasonable? Is it something that has a permission that you don’t mind being outside your control? If so, create a special group with access to that specific permission plus normal user access, and give it to the VP’s. That way you can be seen as enabling work they feel the need to do while not giving away the keys to the kingdom.

If it is something that you should feel you need to be able to manage, stay calm. Explain your concerns over what this access could mean long term. The classic example is the ability to create projects. JIRA, by default, will create new permission schemes, workflows, etc whenever a new project is created. However, this will lead to system bloat and eventually slow down the system. Explain that the VP will be able to request new projects from you, but you need to be the one creating them in order to set them to a default set of schemes and remove the bloat. Most reasonable people will be fine with this so long as they still have an avenue to get it done.

Day Three

Now that you know that you won’t have someone coming up behind you to undo changes you are putting in place, start looking at the instance in further detail. How many permission schemes are there? How many workflows, custom fields, etc? How many of those are going unused? Start making a plan for what to clean up.

I usually start with the low hanging fruit of unused workflows. These still count as far as JIRA is concerned, so cleaning them up will help JIRA perform better. And because they are unused, most users will not notice that they are gone.

My next target is usually permission schemes. Unlike unused workflows, you will not be able to clean these up today, but you can at least start strategizing and getting a conversation going. Typically, you can break down permission schemes into four general categories:

• Everyone can see, modify, work on, and create issues
• Everyone can see and create issues, but only the team can modify and work on issues
• Everyone can see the issues, but only the team can create, modify, and work on issues
• Only the team can see, create, modify, and work on the issues.

Exactly which permission nodes map onto these for broad generalized schemes will vary from org to org, but in practice I find that these four are enough to cover most use cases in JIRA. So my plan is to usually set these four up to use Project Roles so I can reuse them on as many projects as I can. I’ll then start working down the project list to adjust them as needed. You will need buy-in from the Project Manager for each one, but if you write a document explaining in detail exactly what the permission schemes are, and how this would empower them to manage their own teams access by using project roles. Once you explain all the benefits, buy-in will almost always happen.

Day Four

On Day Four, You will usually have a good bit of dialogue going at this point. You’ll probably spend this day working through incomplete tasks from the previous days and continuing on with team meetings. However, as this is going, you should be taking notes as to what projects, if any, are being unused. Revisit the JQL from Day One, and instead of looking at the active projects, start weeding out the projects that haven’t been updated in at least a month.

However, don’t assume just because they aren’t used that they are safe for archival. Track down whoever is/was responsible for that project. Ask them why the project is going unused? Did it not meet their needs? If so, how? Was that project completed? Or did a re-org make it obsolete? Figure out why each one isn’t being used, and come up with an appropriate answer for each. A lot are likely to be archive-able, but some just may need some user education and tweaking by an actual JIRA Admin to get it back into use.

Sometimes while doing this, you’ll run into the “JIRA Sucks” people; that is people who hate the platform for one reason or another. It is amazing how many people draw this conclusion due to a misconfigured JIRA instance.

I deal with these people by agreeing with them that JIRA can suck. No really, nothing wrong foots a person and brings down there defenses like the JIRA Admin – a guy who’s career is based of managing JIRA – agreeing with them that JIRA can suck when configured wrong. But this can get the conversation started about exactly what they didn’t like about it. You can then explain that when managed by someone who knows what they are doing, most – if not all – of those problems can be solved, and then explain how you plan to fix it. Show these people that you have a plan and are willing to put in work to make their experience better, and they will likely give you a chance.

Day Five

So, Here you are, five days in. You are meeting key players, getting to know your teams, and coming up with a plan to meet your user’s needs. You will still likely to be having a lot of meeting and introductions to people, but take some time today to prepare for eventualities.

By this, I am saying you should have a run-book available to your team. A run-book is a document that can tell people who are not 100% familiar with a system what to do in the event of downtime. It should contain the following:

• What checks to perform to be sure JIRA is down rather than a network problem
• Information on all services that support JIRA (i.e. Database, File Share, Proxy, etc), including how to check that those are working correctly and are reachable from the node.
• Basic troubleshooting steps to try if JIRA really is down before calling you.
• Backup Procedures and Location of backups
• Logs to capture if a problem is detected
• Contact information should things need to be escalated to you.

A run-book won’t prevent every call to you on your off-time, but it’s at least something to help whoever is on-call do something to attempt to resolve a problem before you are called in.

And You’ve survived!

Now, you won’t have every item on the list above completed, but you will have gotten the ball rolling. After all, “A journey of 1000 miles begins with but one step.” You’ll have set yourself up for a good tenure within your org, while establishing yourself as the point of contact for JIRA problems. So take a break, enjoy your weekend, and rest up while you can. Now that people know that you are willing and able to help them with JIRA, your work is only just starting.

And with that, I’ll catch you next week! Until then, this is Rodney, asking “Have you updated your JIRA issues today?”