How not to shoot yourself in the foot with Jira – Part 1

Some say that there is nothing more helpful when building a group (or even a team) than a common enemy. In the absence of such (or with the predominant culture of superficial political correctness) having a scapegoat seems to be the next best thing. You know, the person that always messes up, the tool in the box that is not as sharp as the rest or the spark plug in the cylinder that somehow always finds a way not to fire.

There is always the black sheep in the herd, and my observation among the Agile practitioner community is that we also have our favourite conversation punchline generator… Atlassian Jira.

I mean seriously, I have never heard the name mentioned on a meetup or a conference without a wave of ironic laughter filling the room, and the irony being that the majority is using it.

But is it the case that Jira (you can probably substitute the name with asana, VersionOne, Trello, etc.) is just a necessary impediment, or maybe we just blame the rifle for shooting ourselves in the foot?

Some time ago I said “enough!” it’s time for someone to take the stance and start the discussion about the dos and don’ts of Jira in a proper Agile environment.

This post is a first in a series documenting my personal trials and tribulations with Jira and why I’m brave in admitting that there are some situations where it can be an asset.

“Managers are using Jira as a stick to beat us with.”

This statement is a popular one. Why is it that whenever a Manager sees a burndown/burnup chart, he or she immediately panics? Or when I describe the tool the first question is always “what happens when it goes off track?”.

First and foremost, it has nothing to do with Jira, I think that the root of the problem is that it’s just a tool, serving the data rock cold, with no comforting excuses or a convenient person standing by.

In my opinion, the issue (especially with the more senior management) is that they always had the data presented with a commentary. Having a person that they could associate with what they see, and obviously to blame (or pat on the back if needed). What we have to factor in is that with Jira they are just sitting there by themselves thinking that something is wrong, and unfortunately nobody is doing anything about it… guess what, in my opinion, it generates an adamant incentive to act. And act they do, typically assuming the worst case scenario and throwing the baby out with the bathwater. We all know it, but is there anything that can be done here?

First of all, if you have a proper Product Owner in your process, he or she should (hopefully) be aware of the accountability for the product. But in my experience, it is often challenging to say “no” to the CXX, MD or the Head of something that just “wants to know.”

If you have the Agile Facilitators available in your organisation (or maybe you are one), in my opinion, their role should also have some focus on the middle/senior management.

So before giving them the magical Jira account and the URL to the team report how about briefing them on some vital points helping them cope with what they see:

• Trust is the fundament of Agile; there is no point in pretending that we have an environment where Agile can be successful without it
• Data without context often leads to wrong conclusions
• There is an Agile ceremony called Review that is an ideal place to get the current status with the necessary context
• If you see something wrong (and you will), don’t panic! The Agile team will welcome your feedback and deal with the issue (if there is one)

In my opinion, those help a lot. Sure you may hide your data from the stakeholders, change their Jira passwords and have your stand-ups in the darkest corner of the boiler room, but I’m sure you know that it’s in your best interest to keep them educated. After all, in an ideal world, they can (possibly) be helpful.

“Using Jira prevents face to face communication.”

Well, most of the time a tool is just an excuse not to see another person. Smoke signals, emails, IMs and all the things in between have been created just for that very unfortunate reason. With Jira, I think it’s even more twisted because some people manage to use it with some “meta-communication” in mind.

Have you ever seen a stakeholder trying to expedite a ticket? My all too frequent experience is that instead of raising a ticket and addressing the team before/after the stand-up or just popping an email outlining why it is so important – the stakeholders start exhibiting some very strange kind of behaviour. What happens is the ticket gets ranked at the top, marked as a blocker flagged and assigned to a team member that our favourite stakeholder believes to be the best person to deliver on it, if it would be possible they would put the Gangnam Style emoji in the title to draw even more attention to it.

I have to admit it is surprising how often I see that happen, and yes it seems that Jira somehow encourages it. I think it’s a classic case of “I need to do something so I’ll do the easiest thing maybe it will help” scenario.

My personal recommendation here is to agree on a standard way of communicating a need for expediting work along with clear rules and protocols. However, in my opinion, one should remember that if there is one place that a WIP limit should get imposed it is the expedited tickets column.

“Using Jira causes conflicts.”

I still remember how surprised I was when a Jira ticket has directly been blamed for creating a conflict for the first time on a team that I served. Don’t get me wrong; I don’t negate the Storming phase of the Tuckman cycle, but somehow people manage to use Jira as a conflict facilitation tool. I think that there is one feature in particular that is a giant culprit here: the ticket assignment mechanism.

When you look at it closely, the act of assigning can be an incredible power play, and if a person is quite keen on his or her place in the social hierarchy of the team (let’s not lie to ourselves, there is always one), it can spin up a conflict in seconds. Especially when you have a bit of a back and forth between for instance a Dev and a QA using the tool to play a finger pointing game of throwing a hot potato over the imaginary fence.

Seeing it time and time again I decided to use a very profound experiment, for a week we disabled the assigning function for a team and decided only to use a pull assignment (everyone has to assign the tickets to themselves). It worked, not only did we remove the “assignment tension” altogether but nudged ourselves toward more communication.

To sum the points from this post up it is important to educate the stakeholders and be aware of the non-obvious meaning of your actions in Jira.

I’m hoping that this post will help you to dodge a bullet or two, but unfortunately (fortunately in the case of blogs) there still is a lot more pitfalls to avoid.

This post has originally been published at Adventures With Agile