How to get your non-development teams on board for using JIRA Software

Background

As a Jira Administrator, I am passionate about helping others get the most from their Projects, especially within my current workplace. All of our software development teams use JIRA Software. Initially, our non-development teams were not using Jira within their current working processes. Fortunately for me, I was not the only person to notice this opportunity.  

If you’re short on time, feel free to skip to the TLDR at the end of this article! Otherwise, grab a mug of something and settle in for some best practices on getting your non-development teams on board with Jira.

 

How it starts

The initial idea of using Jira was suggested as a way to help the Sales team with their Change Management process. They needed a tool to help track incoming change requests and to report their current statuses, Jira fit the bill.

voice-of-customer-860x450_c.jpg

This was informal, word-of-mouth, my colleague was not actively searching to change the Sales team’s Change Management process. Understandably the Sales team,  like any team with established working processes, needed to carefully consider any changes to working practices, ensuring clear business values are apparent, as any negative impact could affect client relationships and potential business.

This is the crux of “how it starts”: we apply a gradual process of gathering requirements for teams and groups of individuals that could attain positive outcomes from using Jira. Be aware though, it is likely to be difficult to change the tools used by other teams without buy-in from their Department Leads. Instead, you need to show potential users that Jira will get them what they want with greater ease and accuracy than their current system.

 

Breaking down the barriers

So, you have some buy-in and you want to maximise its potential. Time for a meeting!

e87c4e9830a7b39d1aaeceeaedffc5ca.jpg

I sat down with a representative member of the Sales team, listened to their issues, reassured them that I could create a solution that would be specific to their needs from the information they provided to me at today’s meeting. Oh, and of course, thanked them for their time.

I completed all the heavy-lifting and custom tailoring for this project before the next meeting. After building the tailored experience for the Sales team, I had a new board, a new issue type, new fields, a few custom field configurations, and of course existing data imported from their current system.  Focus should always, at first, be on project structure and content so that when it comes time to hand over the project, the Sales team is ready to dive in.

 

We must crawl before we can run

It is the day of the demonstration and I have thought about what I want to present, how I am going to present it and when I am going to pause for feedback on aspects of the solution. I started with the Kanban board, showing the Sales team the big picture of their entire process for managing change requests. There were existing change requests present on the board already (data migrated from the current system to JIRA) to enable the Sales team to see how and where their change requests were represented. Next, I moved onto creating a new Change Request in the project and demonstrated where new requests would be displayed on the board.

From there, I gathered feedback that highlighted the team’s reservations about using a new tool. To mitigate these concerns, I explained clearly that I would make myself available to support them with the onboarding process directly, and we could work on a schedule to transfer all content from one tool to the other.

Tip: If you are going to demonstrate to a prospective user, try to relate the initial part of the meeting to their current system or known content, this will help put the prospective user at ease as it is familiar to them.

Give the prospective user only what they have asked for, nothing more as this will only confuse them and strengthen their resolve to retain their current tool.

 

Where do we go from here?

The demonstration was complete, the Sales team was happy, and all I could do was think, “Ah, I should have shown them how to set up Components” and, “Oh no, I could have automated some of their workflow steps to make things easier for them.” However, I had set up everything as the prospective user had asked (no more and no less), fulfilling the users requirements and expectations. Attempting to make changes to improve the project at this stage would generally be counterproductive as it is likely to overwhelm any new user.

There will always be opportunities later to respond to further questions and make suggestions for improving their project when new users are familiar with Jira. Providing the aftercare support allows you to speak directly to new users and introduce new configurations gradually that will positively affect their project.

methodology.png

(TLDR) Too Long, Didn’t Read

I find reading through long articles just to find the main points very time consuming and I lose interest quickly. With that in mind here is my breakdown to bring any type of team into your Jira instance.

  1. Actively listen to people about their problems regarding tools and team processes; you may have a potential solution for them.
  2. Reach out to senior members within your organisation who have a positive interest in Jira. Ask them if they know of any issues that other teams are currently experiencing.
  3. Speak to one of the members within the affected team (it does not have to be the team lead). Find out if they are having issues with their current tool, what limitations their current tool has, and what the team would like to get out of their current processes.
  4. Plan out a viable Jira solution for the team (No need to implement in Jira at this stage as it could be wasted effort if it turns out the team isn’t amenable to the change).
  5. Speak to the affected team’s Department Lead (either formally in a meeting or informally), ask them if they have any limitations with their current system. Let the lead know you have been working on a solution and ask for a date they are free for a demo.
  6. Build your Jira solution. Try to match the project with the team’s current tool and add existing content (A familiar tool is an easier tool to transition to).
  7. Get feedback and ask if the Department Lead would like to trial the solution. Offer active support where possible.
  8. Actively listen for feedback 😊.  

Let me know if you have any questions about moving non technical teams to Jira in the comments section below!

7 comments

At DEISER We will be onboarding Jira very soon for our content marketing strategy. I think the main aspects to consider are whether Jira Core is sufficiently flexible for an advanced team with complex processes and integrations. 

@Danny Harris Why would you defend Jira Software for business teams as opposed to Atlassian's product vision of one different, simplified product that already adjusts to non-software needs?

@Jaime González-Capitel I can think of several reasons why a business team should use Jira Software. For one, if a business team wants to use an agile methodology, like scrum, they will need Jira Software. A lot of marketing teams, for example, are adopting agile.

I wrote a book about it, arguing that marketing teams should use Jira Software to run scrum (or kanban for that matter).

I don't think the issue is "business teams should use Jira Core because Atlassian targets Jira Core at business teams." I think a team should pick the tool that best suits its needs today and in the anticipated future. 

You could set up your entire content marketing strategy in Jira Software. You could write your next 30 page white paper in a scrum process of six (or 8), weekly sprints, gain feedback at the end of each sprint, and ship a really good paper. It all depends on how you want to work. 

Bill, I've heard about this book how can I get hold of a copy?

Matt, It's on Amazon. The art of agile marketing: A practical roadmap for implementing kanban and scrum in Jira and Confluence. Next time I see you at an AUG, I'll bring a copy for you.

Danny Harris Community Champion Jun 11, 2018

Hi @Jaime González-Capitel,

Great Question, I will answer it as best I can :)

@Bill Cushard is correct, ZeroLight utilises Agile methodologies throughout all their teams. For established processes we mainly implement Kanban, for our Sales team this was a perfect fit for them. 

I can understand Atlassian's product vision for JIRA Core, though I cannot presume to strictly define each team with only one product or another. Instead, whenever I am working with a team, I gather as much information about their working processes and contingencies, prioritise their needs, and build a flexible solution with the requirements in mind. For example, the Sales team are now able to set up Versions with end dates that run in parallel with project stages, so that completed Change Request issues can be moved onto the corresponding JIRA Project for the development teams to implement. 

@Bill Cushard, spot on :D. I am going to have to get a copy of your book it sounds fascinating.

You could set up your entire content marketing strategy in Jira Software.

I can confirm our Marketing Dept utilises JIRA Software for this.

Hope this helps

@Danny Harris The best part of your article is near the end

The demonstration was complete, the Sales team was happy, and all I could do was think, “Ah, I should have shown them how to set up Components” and, “Oh no, I could have automated some of their workflow steps to make things easier for them.” However, I had set up everything as the prospective user had asked (no more and no less), fulfilling the users requirements and expectations. Attempting to make changes to improve the project at this stage would generally be counterproductive as it is likely to overwhelm any new user.

....in particular the part about not being tempted to also show people this and that and the other million things they could be doing, so as not to overwhelm them. That is definitely one thing I tried to get across in my book....that its important to start and start small and build new habits and not try to be perfect and do everything at once. If we do too much upfront, we get overwhelmed and discouraged and then we stop. Stopping is no good. 

Hi @Bill Cushard thanks for your feedback! I'm aware of your book and it's planned for my summer readings.

And thanks @Danny Harris for your insight!

Comment

Log in or Sign up to comment
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Thursday in Jira Service Desk

How the Telegram Integration for Jira helps Sergey's team take their support efficiency to the bank

...+ reading Fantasy). The same is true for him at the bank he works for: Efficiency is key when time literally equals money. Read on to learn how Sergey makes most of the time he has by...

314 views 2 4
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you