I think the Agile Manifesto is an exercise in subversively asking management for a very reasonable-sounding thing that is completely impossible: autonomy. Every line poses a threat to a well-known corporate best practice, and the natural reaction is to co-opt the message and bring the items in the left column back into the right column.
In the case of Scrum, it's that "individuals and interactions over tools and processes" line. Scrum did start out as a popular Agile methodology among developers, but because it was the most prescriptive and process-oriented of the methodologies, it got adopted and twisted by management and turned into a tool to reassert authority. Now it reasserts that tools and processes are, in fact, more important than individuals and interactions, but this time with the "Agile" label.
I'd love to try working on a Scrum project that doesn't rely on JIRA. Just notes on a corkboard with a quick "need anything?" conversation in the morning.
> I'd love to try working on a Scrum project that doesn't rely on JIRA. Just notes on a corkboard with a quick "need anything?" conversation in the morning.
Don't you find value in keeping the digital record of the work? For example, if you want to keep track of dependencies that a given task has; or want to get back to the description of a given piece of product that was captured in a ticket (a user story, links to designs, references to other documents, etc.) after some time has passed? Notes on a corkboard are transient; tickets in the Jira are permanent. Isn't there value in that?
BTW, why do people dislike Jira so much? Apart from it being slow or not allowing assignment of tickets to more than one person?
That's exactly why. Bad JIRA implementations can easily incur 5-10 seconds of wait time just loading the page alone. JIRA as a tool allows everything under the sun for management to configure, which makes management do exactly that, configure everything under the sun.
It's not unheard of having to tick 15-25 fields + checkboxes + dropdowns (most of which could've been autofilled or cut and made lean) because management likes it that way. I hope I don't have to explain why a crowd largely composed of "I hate doing the same manual work more than once" collectively sighs at this notion.
Then you add onto that a workflow which requires one to open JIRA multiple times, multiple stages etc. and these people end up spending a lot of time on something they feel is incredibly inefficient. Great way to tank morale.
"But that's a problem with the use of the tool, not the tool itself!"
And we've seen this story a thousand times. If tools allow for weird things, weird things happen. Beyond that, I don't really see why people prefer the Atlassian stack which shows similar issues all-over and is a hassle to cobble together, when GitHub and GitLab do these things out of the box. The common complaint is "well GH/GL don't have X and we really need X", when the organization has never tried doing things without X.
There's value in keeping records for projects that last.
But there's a slight difference between keeping records for accountability (just do the bare minimum to show that work happened as requested/regulated) and keeping records for documentation/action/archival.
The difference shows in the care you take to design and operate those records.
As for Jira: 1/ it IS slow 2/ it IS bloated (visually and functionally) 3/ it does work for a very specific limited number of ways to do things - but never yours 4/ when you start to look at the APIs and data model, you start to understand that it's been designed/built by people not having a clue what it was going to be used for, and by who - and it definitely shows.
Bugzilla is old, clunky; Trac is... extremely focused; GitHub issues are limited. But I would more happily go back working with any of these and plug into additional tooling rather than with Jira.
Granted, none of these allow for a clear understanding of a ticket lifecycle, or a whole project. But that's because this belongs in a narrative, not in a dashboard. And a lot of people don't like to write or value written docs.
> Granted, none of these allow for a clear understanding of a ticket lifecycle, or a whole project. But that's because this belongs in a narrative, not in a dashboard. And a lot of people don't like to write or value written docs.
Maybe there is a market for "literate programming merged with project/task management" where the narrative is maintained as a source of truth and individual items can be queried (or compiled) out of it. The narrative could based on some of the ideas in this article even: https://www.joelonsoftware.com/2000/10/02/painless-functiona...
We had that at Symbian in 2006. It was great. As a scrum master I did later use Jira to manage a backlog along with the product owner, but it was just for the two of us: all the stories were written on cards when they were ready to be worked on by the devs. Epics were also written on cards on a big wall... but each of those had an accompanying document / wiki page.
>Individuals and interactions over processes and tools
and I would argue Scrum is a process and a rather heavyweight one. Thinking in terms of Scrum instead of your team/members and their preferences is getting it backwards.
