Sunday, January 20, 2019

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

Sunday, January 06, 2019

What's wrong with collective code ownership?

The Consultant’s answer of course would be “it depends.”

For now I just would like to focus on one important issues: In today's world ‘code’ is something quite different from what ‘code’ was in the nineties where we had things like a smalltalk image in which all the code of the project resides. Today we have things like infrastructure as code, configurations that are in some cases more complex that the software itself, pipeline-code, glue-code and many more things that affect the usability and usefulness of the system under discussion.

Therefore I propose to extend the concept. Let’s move on. Or –from my point of view– let’s get back to the original idea.

IMHO today what’s needed is an interpretation of collective ownership that engulfs the whole system. Collective ownership in this idea is not so much the idea that anyone is allowed fiddle with any item of the system.

To me today's idea of collective ownership means that anyone is expected to make all the changes that are necessary to keep the integrity of the system as a whole after some change or addition. This especially includes involving potentially affected parties and is much more about everyone’s responsibility for the whole system. And in today’s reality there are only very few people who can change all the kinds of code. Therefore, form my point of view, shared ownership also includes the responsibility to collaborate.

till next time
  Michael Mahlberg