The Anti-Pattern of Jira-(Mail)-Notifications

When you use Jira the way it was meant to be used – as a bug tracker with customer facing interfaces – it might be quite okay to use mail notifications. after all, in this scenario it is quite possible, if not even intended, that issues enter the system without any interaction from the people working with the system.

If you use Jira as a replacement for a physical (agile) board things are different.

One of my favorite tweets reads something like “Individuals and interactions over assigning someone a jira ticket without even talking to them.” This not-so-subtle reference to the first value-pair of the Manifesto for Agile Software Development summarizes nicely what’s wrong with many so-called(2) agile projects these days. There are other things as well –lots of them actually- but for now let’s track focus on this issue.

The original statement "[…we have come to value] Individuals and interactions over processes and tools“ puts a very strong focus on people and their interactions. And in the early agile projects I experienced (around the turn of the century) that was a big part of what it was about. Visualization (index cards pinned on boards) was mostly used to enable self organization and document thing that the people already had talked about. As a friend of mine pointed out much later, when asked about using a physical boards: “The intelligence congregates in front of the board.“

When working in an agile team (e.g. a team really using XP) and if that team decided to use a (physical) board, everyone sitting in the vicinity of the board notices when something the team is working on changes its status. Because each time something enters a new state –a state for which the members of the team themselves have decided that it is relevant for their work–, a person walks up to the board and moves a card. Whether or not that is of interest right now is everyones own decision. But –since the whole team sits together and works on a common goal, without several other project interfering from the side– it is very probable that people will come and have a look rather soon. Even though they would all be informed at the next standup anyway.

This approach is quite powerful, when the cards represent things the people who work with them actually know.

Appearance: Real Life Jira Notifications
“Jira mail notifications do exactly the same” - yes, sometimes they can... “and you don‘t even have to be in the same room” – yes, that is where the trouble starts (because for all Jira knows, you could be in several rooms at once) “and you can even have them for lots of projects” – yes, and this is where it really starts to become a problem. (Because in real live we have those boards in different rooms and we only notice thing that happen where we are. When we get information for things that are not relevant for us now we tend to go numb for that input channel to avoid information overload.)

I saw many organizations where people configured their mail-program in such a way, that Jira notifications got sorted away without ever distracting them from important work. (There words, not mine. Seems to me like those notifications where not important for what they did most of the time.) For me this is the final indicator that the organization has started to value tools and processes over individuals and interactions. In an Environment where the board has the same importance that the physical boards had in the early days, it would probably be visible all the time and everything that happened on the board would be of at least some relevance to everyone in the team. Because –as mentioned earlier– they all work on the same goal. Of course that is not feasible for all environments, but then maybe other approaches would be more useful. But that would be another story.

If you try to work in an agile manner and think you need Jira mail notifications something might be wrong. If you work in a lean manner things might be slightly different but only to a point. And once you “need” mail rules and filters to manage your jira mail notifications, something definitely is wrong from a lean and agile point of view.

Give switching of those notifications a try – after all, you can always look at the board to find out what’s up - can’t you? (If you can’t you've got yet another problem)
Try to find out what you loose if you switch them of altogether and devise ways to address those needs. (Mail-Notifiations might be helpful in a distributed setting, but then again an IP-connected Lava-Lamp might be helpful for more than just the build status...)

till next time
  Michael Mahlberg

The Trouble with Jira

The trouble with Jira isn't (only) the trouble with Jira. It’s rather the way it gets used.

Remember “Context is king” - Jira might well be an excellent bug-tracker. As an Agile and Kanban tool the opinions definitely differ. From my personal experience with many real life implementations I would say that Jira is one of the bigger issues preventing an agile mindset. People from the Lean and Agile communities tend to agree in private conversations (and some even say things along that line of reasoning on twitter).
But as soon as corporate reality strikes, those voices get less loud and the conversation shifts more towards “It can be made to work – millions of users can‘t be that wrong.”

Well, if we have to “make do with what procurement decided to buy”, here are some things I consider to be vital to make it at least not unbearable.

Something like Jira should be a tool. But it should be only one tool. Amongst others. Not the ”one tool to rule them all.”

As long as you have

• enough machines available to permanently display uncomfortable information (and a way to secure them from unwanted access) (Permanent: Without exchanging content every few seconds – yes, that might mean e.g. two different machines, or at least displays, for boards at portfolio level and at team level. In the same room. Gasp!)
• enough rights for the people who actually use the boards to edit boards on the fly (and the same for workflows, if they choose to do so) whenever the teams needs to
• enough knowledge in the teams to be independent from central administration
• the willingness, tools, and knowledge to generate additional information (mostly statistics) outside of Jira

you'll probably be fine. (-ish)

Otherwise – in my experience – you’ll soon hit a glass ceiling consisting of (amongst other things):

• change cycles (to Jira related things) that take longer than an iteration
• information buried in dashboards that are theoretically available but never looked at
• Reliance on Jira-provided graphs and numbers (not exactly tailored to your needs)
• An unwillingness of people at all levels to gradually modify their processes
• a general agile-tool-fatigue

Oh, and on an –not really- unrelated note: You can copy and modify a lot of things in Jira - even if you don't have the rights to change the original.

till next time
  Michael Mahlberg

P.S.: Of course one could blame Atlassian – the company behind Jira – for introducing all those access control mechanisms and thus promoting a command and control culture in the first place.
But that really wouldn't be fair. After all, the core of Jira is a ticketing system. Designed to control people by means of centrally designed workflows.

The whole part that Atlassian sells as “Agile” nowadays used to be a plugin, called “greenhopper.” And if customers demand "Tools to enforce Processes to control the Interactions of Individuals" then why should Atlassian remove those restriction. Oh, wait there was Individuals and interactions over processes and tools, ... well... Of course there also is ...and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact

If you can't avoid Jira, at least have an admin on your team

I used to be one of the people in favor of electronizing your task board using jira with the Greenhopper plugin – of course only after starting with a paper version first. Greenhopper has morphed into something called Jira Agile, accompanied by something called Jira Kanban.

And I have to tell you: am very weary of Jira Agile and Jira Kanban.

Especially if there is a central administrator who is in charge of the tool-handling.

Agile processes (and lean approaches like Kanban as well) almost always include a section on how to improve the process – called a retrospective in some processes or an operations review in some others.
This means that the process is meant to be changed. Often. From within the team.

Modeling the team’s process in a tool that is so complex that it makes economic sense to have someone outside the team cater for its administration makes it almost prohibitively harder to change the process.

And a lot of the admins I’ve met are so overburdened by too many projects that they have to optimize. For example by using Jira workflows (i.e. process-definitions) for more than one project. Which might be good, because: reuse!

But then I hear things like “our jira admin doesn‘t allow that” or “I think we‘ll have word on that from our jira admin in a couple of days” or “yes, we could try that – but I’m afraid it might break some of our reports.”

How is a team self-organized when they have to ask for someone else’s permission to change the process? Not so much, in my opinion.
And if they are worried that their process might break, then obviously “working software” isn’t the primary measure of progress any more.
If they have to wait “a couple of days” to find out if they can implement the process changes they came up with in their process improvement meeting, then – I would say – their process isn’t exactly agile any more.

Don’t become that team. Keep control of your process – even if that means you have to administer yet another tool.

till next time
  Michael Mahlberg