re: Is Jira an antipattern? VIEW POST

FULL DISCUSSION
 

It does seem like Jira's hyper focus on the little pieces encourages a waterfall approach. Each issue goes through a waterfall. A sprint is successful if it finishes its waterfall in x weeks.

That's how I was working at a former client (mid sized company). After a while, they hired an agile coach to explain agile to the PMs (and after to the devs) but in the end the only things that stuck with the PMs were: sprints and tickets. Sprints were just used as containers to do as many tickets as possible and tickets were shuffled around week by week depending on possible changes of priorities or upper management requests. They basically ended up doing "agile waterfall" in a few teams. In another, the one where the coach was more hands on, the whole "goal" was far more present (and Jira far less).

Going back to the article:

“Implement the Upload button” says the ticket; so that is all that is done. The ticket does not explain that the larger goal of the Upload button is to let users back up their work. Perhaps it would actually be technically easier to automatically upload every state change, such that the user gets automatic buttonless backups plus a complete undo/redo stack. But all the ticket says is: “Implement the Upload button.” So that is all that is done.

After a few iterations of this in different companies I've worked with and various chats with fellow techies I came to the conclusion that this is due to the lack of UX designers working side by side with PMs from day one. All the PMs I've ever worked with more or less openly regarded design as the following: "please designer, these are the requirements, now do the wireframes and mockups to send to the devs". So, in that "school of thought" of software development, Jira is perfect because it feeds the ego of the developer closing the tickets, feeds the ego of the PMs that sees the tickets closed and so on. If the app ends up being subpar, well... you can just open new tickets to correct it :D

In truth, this is not an issue of tools but of communication and roles and team management.

 

In truth, this is not an issue of tools but of communication and roles and team management.

#bestofdev :)

My current PM is very upfront about working at the Epic level. Like, she at the end of the day doesn't know what the nitty gritty of what we're implementing is, she is mostly in meetings with our UX guy or making sure overall features are being prioritized right.

On the one hand, cool, someone with a vision for the actual app. Normally I feel like since I'm working at an end to end level, I'm the only one who ever sees that. On the other, though, we're not really able to mix epics her way. It might make more sense for dependencies to work on a few api layer things at once to be prepared for the UI stuff once the wireframes are done, instead of scrambling before a release date to do everything all at once to Ship It.

Now that I'm on this rant, I'm a smidge disappointed the author didn't address how date driven Jira is. Every sprint has a day countdown. Every issue has dots for how many days they've been in a swimlane. Every release has a date. Dates are everywhere as the target rather than points or epics or something. Shouldn't we be more focused on the actual stuff of the app?

 

Every sprint has a day countdown. Every issue has dots for how many days they've been in a swimlane. Every release has a date. Dates are everywhere as the target rather than points or epics or something

Basically like one of those social networks full of metrics causing anxiety to the users :-D

On the one hand, I love metrics. I like Jira as a tool for obtaining metrics.

On the other hand, for gods sakes, don't compare teams using those metrics. Keep them internal and use them for retrospective discussions, not dick waving in front of management.

That basically summarizes my awful 15-page paper on Agile metrics from my grad program that I alluded to in my comment to @ben xD

code of conduct - report abuse