What are common themes you've seen across successful & failed Jira Software implementations?

[Sarah Schuster]

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to get your expert advice to help new or first-time Jira Software Admins be successful. This advice will be incorporated into our inaugural New Jira Software (Cloud) Administrator Playbook (release date: Spring 2018) - we are all so excited!

I'm amazed at the responses seen for the first thread topic, and I'm hoping to get your expertise on this week's topic: Jira Software Implementation Success

So discussion topic #2 (of 8): What are common themes you've seen across successful & failed Jira Software implementations?

Let us know below!

Sarah

[Jack [AppFox]]

Let me start off with a handful of good and bad things I've seen over the last few years - Jira Software Cloud focused - I focus on the application over the more organisational aspects like a good Scrum Master and following Agile Practices correctly ;):

Successful

• Using Dashboards and creating Dashboards for each of the Roles in your Projects, which presents relevant information to them for their Job Role.
• Using Agile Boards with appropriately customised options (Issue Detail View, Card Layout and Swimlanes) and knowing when to separate into multiple Boards.
• Use a planning plugin (e.g. Planning Poker) to start increasing your teams' abilities in estimating work correctly.
• Using Jira Portfolio or Structure to plan at the portfolio level and trace from theme/initiative level down to the story/task level.
• Jira Installations with a dedicated individual or team managing the system and ensuring that changes are consistent.
• If using a testing plugin, use one with traceability from requirements (e.g. Stories), to Test Cases, Test Executions and finally to Defects.

Failed

• Users/Teams unwilling to standardise business processes - e.g. your company has 20 different development teams and each of them has their own Workflow, Custom Fields and Board configuration.
  • This acts as a barrier to entry for users to change teams and makes administration more complicated.
• Installations allowing users to be administrators or 'temporary administrators' of the system without formal training or certification.
  • Building up Technical Debt (e.g. making changes quickly/sloppily for an important member of staff) is worse than investing the time to do it properly (schemes!)
• Misunderstanding the Quick Filter functionality. e.g. having a list of 40 different Quick Filters instead of (a) Different Boards or (b) Dynamic Filters (e.g. currentUser()).
• Too Many Custom Fields, Unused Custom Fields, Incorrect Scoped Custom Fields, Duplicate Named Custom Fields :) - not only is it confusing, but you are actually impacting the performance of your system with these mistakes!

Look forward to hearing more successes and failures.

[LeKisha Boswell]

Some of our teams failures have stemmed from various teams having their own workflows, screens etc; however, they want to share issues on boards etc. :(

[Alexander Soutas]

Seems like most of these issues come from Jira not explaining the functionality well enough. Just something to think about.

[BillyP]

Success comes from adoption.  Seek first to know what your most valuable users want/ need and shape the system to deliver.  If you show them cool features, that aren't needed, it won't get adopted.  

The Dashboards are a great feature for this.  With a Dashboard, you can show a widget or a burndown or a status or really anything.  It's best to show the new users what they want more than cool new JQL queries ;)  

As the team learns how it enables their work, they'll find new ways to grow with the product.  

---

Another great aspect is to bringing to light know issues with data.  There are many ways to highlight this within JIRA.  For those teams who aren't in a position to speak truth to power, this can be a tool to 'ease in' the need to do work in a different way.  

For example, while watching the process flow, it becomes apparent that an entire quality control step could be moved up stream to save precious downstream build times.  This information might not have become visible without a dedicated focus.  

You can export your JIRA tickets into a simple .csv file for further review and analysis.  (This really helps with LOTS of tickets )

---

Failed installs usually happen because someone is 'told' to install JIRA and Confluence, and they get installed on the same database, and then it's slow, and then people complain...

Make sure you install with dedicated databases (it's easy, there's documentation)  and reach out early for help.  We're all on the same team!

[Florian Reichl]

If the people involved start to separate their processes, it's gone. So a great lead is obviously necessary. As soon as an instance starts to "split up" their processes, the trouble begins.

[Shannon Davis]

This hasn't been an issue for us.

We have several differnet workflows to choose from.  Some people use the very basic default scheme.  Then we have a software development lifecycle workflow scheme, and another one for groups that are doing non-software requests (ex: install a server, modify a router, etc).

When you get your project set up, you request the workflow scheme you want and it's been working fine.

[LeKisha Boswell]

Agreed - every workflow, screen/permission scheme, dashboard, scrum/kanban board etc does not have to be the same; however, you don't want too many customizations either.  Depending on the size of your instance you may want to provide guidelines and a few options team can elect without creating a nightmare for admins or new users by allowing it to be a free for all.

[LeKisha Boswell]

The tool doesn't work if you don't have defined processes (the tool is only as good as the process). The biggest hurdle for my company was changing the culture to better understand that any decisions should be based on the balanced team vs the individual resource. Getting teams to adopt some sort of standards to assist with consistency added to the challenges. Additionally, I didn't find themes beneficial outside of Portfolio.

[Aaron Ko]

In terms of "implementation", the word seems to mean end-to-end, so I will just focus on the actual usage of JIRA Software.  

For me, the biggest challenge begins with Admins, not the users.  The Admin(s) manages users, permissions, projects, issue configuration (workflow,screen,custom fields), and best practices.  

Whether it's a full-time role, or a part-time role, the Admin must not only be the go-to person, but he/she needs to be an Evangelist for the software.  

Beginning with that point, here are my top challenges (and failures)

• Right person, Right role OR Wrong Person, Wrong Role - the Admin must be the right person.   They will drive training, best practices, usability, and overall efficiency.  An Admin without the necessary skills/experience could have a negative impact on all users, if they don't know how to manage issue types, workflows, schemes, custom fields, and most of all promote re-usability.   
• Simplicity vs. Complexity - This is where a "project lead" often believes a more complex project with complex workflows is always better.   In reality, a few issue types, simple workflows are usually better, even for advanced software development teams.  This is really a mindset problem with "project leads" and users.  
• Leveraging Core Features - Too often, users don't seem to know the core features available to them, from JQL, filters (subscription), and especially dashboards.  Another feature is Components, and teams often do not leverage the capability such as default assignee.  
• Content of a single JIRA issue - This is all about best practice, and again it begins with the Admin or "Evangelist".   Poorly created issues are everywhere.  This may never be perfect, but with proper training, users can improve quality and readability of their Subject,Description, and Comments.  

I'm not sure if this was the response you were looking for, but it was fresh on my mind.  

Too conclude, the Admin's job is not done after the software installation, it is just beginning.  They need to be an Evangelist, a Coach, a Trainer, and a JIRA expert.  

[LeKisha Boswell]

Excellent points you've made! I've struggled with each area mentioned. Thanks for reassuring me that I am not alone.

[Tech ProjectMgr]

Having the same screen open when a user logs back into the system, instead of defaulting to the Dashboard or filter. Is this a permission issue? 

[Celik Vedat]

- Users solving issues without even using the Workflow or adjusting statuses. Therefore often smo doesn't even know in wich status a issue is really

- Using the comment function to adjust requirements needed or specify further requirements

- Using fields and screens when they are needed. Request the information you need at the right spot/status instead of overfilling the screens with information smo cannot give --> empty fields

[Dion Jones]

"Using the comment function to adjust requirements needed or specify further requirements"  --aAAAAAAARRGHHH!!!!!   agreed.

[Pedro Felgueiras]

We have what i can consider a successful implementation of Jira. 

The major aspect that help us a lot in the implementation was that the previous tool that we use (Lotus Notes) was horrible, outdated and without knowledgeable administrator of it. 

The first progress that we had implemented was the ITIL for incidents and requests. We had the help of a ITIL consultant that, with us, defined the process without thinking on any limitations of the tools that we will use. The pilot started with a small client and a open mind team. After fixing some aspects identified on the pilot, a migration schedule was define and implemented without questions and doubts. Because of the struggles with the previous tool all collaborators realized the added value and help us with valid suggestions.

After that, the other teams develop interest in Jira, and the ask us for implementing Jira for them. 

Because of the error prof that the humans are susceptible the workflows were constrained and restricted to try to minimize the incoherence between issues. 

Now, all the teams use Jira and are happy with it. 

We have some problems with the oldest collaborators that are resistant to changes but when hey had seen the advantages they become convinced. 

[Sarah Schuster]

What a fantastic success story! Thank you for sharing :)

[Stefanie Chernow]

We recently covered this topic on the Valiantys blog. Essentially, here are a few tips to keep in mind: 

• Limit the number of admins to avoid having too many cooks in the kitchen. 
• Make sure your team adopts the tool rather than fall back to email. 
• Keep the workflow simple and have a final status. 
• Contextualize your custom fields. This will help your JQL search retrieve the right custom field (instead of twelve if you have twelve different projects...).

[Deleted user]

The search functionality is pretty sloppy.

Why can't I type JQL right into the basic search bar? If I do it, then I get an empty search result. e.g., if you type: "project=XXX and status!=closed" into the search bar, then the outcome will be "text ~ "project=XXX and status!=closed"" and obviously that leads to an empty search result. 
Search bar should work natively with JQL; no need to wrap it with the "text~" tag.

[Huey Callison]

Conveniently enough, I have just finished an analysis "Statistical likelihood of the abandonment of JIRA projects" two days ago when I discovered this board just now. Here's a summary of my findings: 
1) Most systemic failures are caused by incomplete, ill-considered, or completely missing requirements. When the business comes to you and says "I need a new JIRA project, make it look just like (other project)", the answer should probably be "...I'm here to help, but what you're asking for is probably a bad idea for a couple different reasons. First, let's talk about what type of issues you're tracking, what your workflow for each of those types of issues is, and what benefit you hope to get out of this?". If projects are set up wrong at the beginning, they're pretty much guaranteed to stay wrong until people eventually get annoyed and stop using them.  
2) There needs to be some sort of connective schema and regular review of same, even between projects that are nominally controlled by different people. For example:
- regardless of how complex your workflows are, all workflows should end in the same state, whether that's 'Closed' or 'Done' or 'Over' or 'Resolved' or whatever you want to call it, it's a lot easier for people to filter on "Status != Closed' than have to remember that, to filter out the closed tickets, they need to type 'Status NOT IN (Closed, Complete, Done, Over, Resolved, Rejected, Cannot_Reproduce, Steve)'. (Who is Steve, anyway? And why does he get his own status?)
- Labels need a data dictionary. Labels that are clearly typos (517 tickets with the label 'wiki', one ticket with the label 'wliki') need to be reviewed and remediated.
- Projects that don't 'sprint' shouldn't have 'sprint' as a required field. If you don't story-point and prioritize and sprint kickoff and retrospective and do all of the other things around sprints, so a sprint is just a meaningless time-box that stuff goes in until it's over and then you have to move all of the open issues to the next 'sprint', why not just save yourself some headaches and just not have sprints at all? How does having them help you? (see "incomplete, ill-considered, or missing requirements", above) 
- Projects where none of the employees even know what a storyboard IS, much less how to do it, shouldn't have a status 'Ready for Storyboard'.  (same as above) 
3) Projects, issue types, workflows, labels, users, groups, permissions: ...all of these things need to be well-documented and need regular review to ensure they stay that way. You should not have open tickets assigned to people who no longer work here. You should not have project owners that no longer work here. There's a difference between 'backlogged', 'deprioritized to the eleventh of never' and 'just plain forgotten about'. And the only way someone is going to know any of that is to regularly review things.  As a JIRA admin, you should have regular (monthly, at least) checkins with project owners to ensure that their requirements are still valid and still being met, that their schema is still valid, useful, and connected to the bigger picture, that whatever their requested improvements are get discussed, captured, and prioritized, and that there are generally no obvious untied shoelaces in what they're doing. 

The best JIRA implementations I've seen have had:
- guidelines for setting up new projects, issue types, workflows, user groups, permissions, and other schema elements, and then
- regular reviews to ensure that defects and enhancement requests were put into a plan, prioritized, and worked,
- an epic on a JIRA admin project to capture and share all of the documentation of those requirements (and also serve as a parent issue for those specific defects and enhancements)  
- at least one test environment where proposed changes could be implemented, experimented with, demoed, and trained, and
- demonstrable usefulness for every member of the team, from individual team members tracking their own to-do list and hours worked, to senior management looking at big-picture dashboards across multiple projects. 

The worst JIRA implementations I've seen have all been missing at least four of those. 

[Matt Doar]

Good summary.

[Matt Doar]

Will your analysis ever be public or presented in some way?

[Monique vdB]

I agree this is terrific but really commented to say: lol @ "Steve"

[Billy Poggi AUG NOVA_ DC]

I know an AUG that would totally welcome the presentation :)

[Cody Somerville]

Regarding:

- regardless of how complex your workflows are, all workflows should end in the same state, whether that's 'Closed' or 'Done' or 'Over' or 'Resolved' or whatever you want to call it, it's a lot easier for people to filter on "Status != Closed' than have to remember that, to filter out the closed tickets, they need to type 'Status NOT IN (Closed, Complete, Done, Over, Resolved, Rejected, Cannot_Reproduce, Steve)'. (Who is Steve, anyway? And why does he get his own status?)

Thought I’d share with you the ability in jql to filter by statusCategory, e.g.

statusCategory = Done

Or in your specific example:

statusCategory != Done

[Huey Callison]

@Cody Somerville: That is some really handy information that I did not have. Thanks!

[Matt Doar]

Or even this:
resolution is not empty

[Brendan Andrews]

If you want to customise JIRA, don't modify the defaults. For example if you have custom fields or custom issue types - add them to custom field type schemes and custom issue type schemes. 

Otherwise by default even simple projects become over-complicated with every piece of detritus accumulated by every project in the instance ever created.

Using custom schemes can avoid hundreds of different issue types and fields being forced upon every project. Because (at least currently) even if you assign a custom scheme with just those you need, there are cases (like changing workflows) when JIRA will show every custom type available. Hundreds of them..