No Jira, No Cry

For those of you lucky enough not to know, Jira is a project management tool, and it doesn’t look bad at first sight:

Troubles start when you need to use it and the other day I had to do a simple thing — open a ticket and put it on the project board. It took me ten minutes to do so I had to ask a colleague for help. True story.

A scroll through a job board these days shows I’m not the only one having problems using Jira. It is so complex that some companies are hiring people whose sole role will be to manage it. Others are outsourcing it to some Jira-management-as-a-service-company:

The thing I find particularly interesting is that Jira markets itself as “The number one tool used by agile teams”. Agile? Hmm, if you need a person whose sole job is to manage Jira or you need to outsource it, that doesn’t seem very agile to me.

But what is this “Agile” that everyone seems to be doing these days?

Sequential development

Before everyone was doing Agile they did Waterfall. It was first formally described by Winston Royce in a paper he published in 1970. Though he never used the term Waterfall in the article, he did include this picture that seemed to remind a lot of people of a waterfall:

Winston also described this model as flawed and the final model/image he developed was pretty different, but this is the image that served as a base of the so-called Waterfall method.

The core idea is to do the planning up front and then follow those sequential steps to build and ship the software. This fits nicely with the old ideas of Scientific Management, laid out by Frederick Winslow Taylor back in 1911. What he said, in a nutshell, is that workers are not to be trusted to organize themselves so you need a separate group of people to develop a process that workers will blindly follow. A separate group of process organizers.

The only problem with applying this approach to software development is that it kept failing.

The Snowbird Meeting

The reason the Waterfall model kept failing is that it depends on stable requirements. And if you ever worked on a software project you know there is only one certainty — requirements change.

This was well understood by a group of developers who gathered at Snowbird (USA) in 2001. They realized that If the development process depends on stable requirements and the requirements cannot be stabilized, then every processing method we use is bound to fail. The way out of this situation is to do to that dependency what Alexander the Great did to the Gordian knot — cut it.

What is need is a different way of developing software. One that will not be dependent on stable requirements, but will embrace changes.

A late change in requirements is a competitive advantage
–Mary Poppendieck

The Snowbird group came up with some values and principles that came to be known as the Manifesto for agile Software Development.

The main points of this manifesto are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

They did not say that things on the right don’t matter, but the things on the left matter more. This thinking was influenced by the Lean Production model whose fundamental principle was: eliminate waste. Everything that does not create value for the customer is a waste. The things on the right can often be just that — waste.

What happened?

If the first (fundamental) principle of the manifesto is “Individuals and interactions over processes and tools”, how come all the Agile teams I (you) worked in are so high on process and tools? It’s all about Jira tickets, putting them in the right lane and God forbid you to add a single line of code without a Jira ticket justifying it…

The root of all evil, according to pragmatic Dave Thomas, is that agile, an adjective, became Agile, a (proper) noun. Nouns sell better than adjectives and a whole “Agile industrial complex” came to existence, selling “Agile”.

Don’t get me wrong. I see nothing wrong with people monetizing their expertise. The problem is that what most of these agile experts are doing is imposing a certain process (as a one size fits all solution).

If the whole idea of agility came as an admission of the fact that we cannot predict all the ways the requirement can change then by definition there cannot be one single solution (process) that will fit all possible environments. The fact that the “Agile people” are now imposing a certain process is what Martin Fowler refers to as an absolute travesty of “agile”.

No Process?

But you do need some kind of process right? So what process do you use? Well, it’s simple — you use whatever works! How to know what works? Use a heuristics-based approach to find out.

Gather a good group of people that works well together at a human level and let them decide what process they want to use. Then do some work, and reflect to see what can be improved. Repeat.

Tools?

What about tools? Same as with process — use whatever works. Or to be more precise — use whatever tool supports your process best. But be careful. Since your process is likely to change you want a tool flexible enough to support these changes. You also don’t want to tie yourself to a specific tool in case you need to switch to another tool that can support your (updated) process better.

There is one tool that fits that description and is regularly available in every office.

A whiteboard, some stickies/index cars, and some markers. That’s it. It’s a great tool because everyone can quickly learn how to use it and it’s as flexible as it can get. If you need a digital tool (as a remote company) then I’d opt for some more general-purpose tool that will give you enough flexibility and only go for specialized tools if you’re sure they will support your process.

The trouble with Jira

It’s complexity aside, my main issue with Jira is that it imposes a certain process on you. And not only that, but I have even seen teams tailoring their process to match Jira, which is just a perversion of the whole “People and interactions over processes and tools” principle.

I’m bashing on Jira because it is a particular tool that gave me most headaches, but all specialized software management tools suffer from the same potential problem. If the specific tool you use does not support your process (in some regard) how long are you gonna fight the tool before you succumb and just adjust your process to the tool?

If Jira is truly supporting your process and helping you achieve agility in your work then by all means use it. But don’t just use it because some Agile expert told you Jira is what agile teams use.