No Jira – no problem

For those lucky ones who have not yet dealt with Jira (if there are any), I would like to inform you: Jira is a project management tool, and at first glance, everything in this system looks very solid and decent.

But troubles begin from the very first minutes of work. The other day I tried to create an elementary thing – open a task and place it on the project board. I spent about ten minutes, but I could not do anything, I had to seek help from a colleague. Everything in this story is true.


Experience has shown that I am not the only one who has problems with the Jira issue board. Jira is such a complex system that some companies hire special people whose only responsibility is to operate the system. Others outsource the management of the Jira system to third-party firms:

But here’s the thing: Jira bills itself as “the number one work tool for agile teams.” Flexible? Hmmmm … if you need a special person or even an entire outsourcing company to manage Jira, how much flexibility can you talk about?

Let’s see what the term “agile” means in general and why everyone is talking about it today?

Sequential development

Today, there is only talk about the Agile methodology, as before about the Waterfall methodology. The Waterfall cascading technique was first described by Winston Royce in articlepublished in 1970. Although the term Waterfall was never used in the article, the description of the method reminded many of the waterfall scheme:

Winston described such a model as imperfect, and the final model and vision he developed was quite different from the original version, but it was this concept that served as the basis for the so-called Waterfall technique.

The main idea of ​​the methodology: any planning of software development processes should be carried out in advance, after which sequential steps should be taken to create and deliver software. This concept fits perfectly into the old ideas of scientific management methods laid down in Frederick Winslow Taylor also in 1911 year… If we omit the details, it idea consists in the following: the organization of work cannot be trusted by the performers, a separate group of people is needed – a group of process organizers, which will develop a sequence of actions, after which the performers are entrusted with the strict implementation of such actions.

The only problem with this approach to software development is its low efficiency – both in the past and now, this technique constantly fails.

Meet at Snowbird

The reason the Waterfall model proved to be ineffective is that it can only be applied if the development requirements remain the same. If you have ever taken part in a software project, then you probably know that the only thing that programmers are absolutely sure of is that the requirements will change anyway.

This was well understood by a group of developers who gathered at the Snowbird ski resort in the United States in 2001. They agreed that when requirements change, the development process will go down the drain, and since it is impossible to prevent changing requirements, any process control methodology used is initially doomed to failure. So what can be done? The way out prompted Alexander the Greatonce cut Gordian knot

The way out was suggested – you need to create a different way of software development, which will not depend on changing requirements, but will adapt to changes.

Changing requirements late in the day is a competitive advantage

-Mary Poppendieck

The Snowbird Group has developed certain values ​​and principles that have come to be known as Agile Software Development Manifesto

The main provisions of the manifesto:

  • People and interaction more important than processes and tools.

  • Working product more important than comprehensive documentation.

  • Cooperation with the customer more important than agreeing on the terms of the contract.

  • Readiness for change more important than following the original plan.

The Manifesto does not say that the words on the right have less meaning and the words on the left more. This way of thinking was inspired by the model Lean Manufacturing, the main principle of which was the constant striving of the enterprise to eliminate any types of losses. Anything that does not add value to the consumer is considered losses… Often times, the words on the right can be associated precisely with losses.

What happened?

If the first (core) principle of the manifesto is “People and interaction are more important than processes and tools”, then why do all the agile teams in which I (or you) have worked value processes and tools so highly? And here I again remember with an unkind word Jira. God forbid to create a task contrary to the requirements of Jira, God forbid to add at least one line of code without the permission of Jira …

The root of all evil, according to the pragmatic remark Dave Thomas, lies in the fact that the word agile – an adjective, has become Agile – (proper) noun. Nouns sell better than adjectives, and even originated “Industrial complex Agile”who sells the Agile brand.

Please understand me correctly. I don’t see anything wrong with people monetizing their knowledge. The problem is that most of these agile experts impose a certain process on us (as a one-stop solution).

If the idea of ​​flexibility comes from recognizing that we cannot foresee exactly how requirements might change, then there cannot be a single solution (process) that would fit all possible environments simply by definition. “Agile experts” impose a certain process on us, and this is what Martin Fowler calls blatant parody on “flexibility”.

How is it, without a process at all?

But some kind of process is needed, isn’t it? Needed, but which one? It’s very simple – use whatever works! But how do you know if it will work? A heuristic approach should be applied here.

Gather a group of reliable people who work well as a team and let them decide which process to use. Then complete the work up to some stage and think about what could be improved. Repeat the cycle.

Instruments

What about the tools? It’s the same as with the process – use whatever works. Or, to be more precise, use whatever tool works best for the process. But be careful. Since your process is likely to change, the flexibility of such a tool should be high enough to accommodate such changes. Also, you should not bet on any particular instrument, because sooner or later you will have to switch to another instrument that is better suited for the (modified) process.

A tool that fits this description and is available in every office is already there!

This tool here is a whiteboard, some stickers / index cards, and a couple of markers. And this all that is needed… The tool is just great as everyone knows how to use it and is as flexible as possible. If you need a digital tool (for remote work), I would choose a more versatile tool – flexible enough, but always specialized. And you need to be sure that such a tool is suitable for your process.

What’s wrong with Jira?

Without going into details, I don’t like Jira because it imposes a certain process on the user. But this is not the end of it. I’ve even witnessed how development teams were forced to adjust their processes to Jira, which is a gross violation of the principle “People and interaction are more important than processes and tools.”

I have accumulated a dislike for Jira because it is from communicating with this tool that my head hurts the most, but things are no better with other specialized software management tools. If the particular tool you use doesn’t fit (in a way) your process, how long will you try to “beat” the tool before spitting and adjusting the process to the requirements of the tool?

If Jira is really effective at guiding the process and helping you achieve flexibility, great – use the system to your heart’s content. But I exhort you – don’t trust Jira just because some “Agile expert” told you that Jira is good and that agile teams work on this system.

Incidentally, Atlassian (the Jira development company) is constantly looking for engineers in various fields, among others we need Fullstack developers and Java developers… If one of your goals is to relocate to a company with a worldwide reputation, then come to study, we will pump your skills and help you to present them profitably in your resume.

find outhow to upgrade in other specialties or master them from scratch:

Other professions and courses

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *