Sometimes I think the problem is really that two things are being tied together: metrics and a todo list. Almost every sprint planning it ends up feeling like tasks are subdivided in ways that make burn down charts look better. I don't want to say developers are all special snowflakes, but the problems with time estimates on creative work is well known, and I tend to wonder if trying to track metrics on these things is fundamentally misguided.
Trello, “Jira Sucks”, and Tool Dysfunction
51–60 of 71 posts
Re: Trello, “Jira Sucks”, and Tool Dysfunction
#52The biggest issues I have with JIRA have to do with it being one of the world's most inconsistent, unintuitive, and undiscoverable UX's possibly ever made. All manner of things are hidden in "..." menus, and any screen will have several such menus visible at once, but they're all different. It feels very much disjointed and like the UX is done in a deeply siloed process that considers only the most local region of th…
The thing about JIRA hate (or love), is that it only has a little to do with the actual product. As the article says, crappy process will give you a crappy experience. But a crappy configuration will do just the same. If you're constantly hunting behind menus to get to stuff it's likely that they've enforced some process on to you but not properly reconfigured the screens or transitions so that you get what you need when you need it.
It took a bit of trial and error but on my team we can work almost exclusively from our agile board and have transition screens configured that will collect the info we need when someone is moving things around on the board.
Now, don't get me wrong- the UX needs a lot of work because it is so inconsistent, but I feel like almost every complaint I've ever heard about JIRA could be remedied by a better implementation. Maybe not solved completely, but remedied to a degree that it's not too bad.
Re: Trello, “Jira Sucks”, and Tool Dysfunction
#53Just use Redmine, it worked well for me and fully open source, though I wish it is not on Ruby, not thing really against Ruby, but this is the only Ruby software I had to run/maintain on the server.
Re: Trello, “Jira Sucks”, and Tool Dysfunction
#54I feel like a big part of people hating on JIRA is that it creates a formal process you have to follow - something enforced by code, and not just "always move your card to this Trello column first". It’s also so tempting for middle-managers to generate bogus reports, based on metrics that the people doing the work know don’t matter.
Even with that, though, I haven’t found anything else as good for linking and organizing bugs and tasks, encouraging collaboration between departments and roles, recording discussions and decisions in the place they’re made, interfacing with the other tools we use to run development, and providing a rich SQL-like way to query tickets.
When setting up our JIRA, we made a few decisions to try and make life easier on ICs and hide the bad parts of JIRA:
* Ignore the permissions system. By the end, all we had were site-admins (who can control billing and add-ins), regular admins (who can edit workflows) and “everyone else”. Setting permissions up properly is tricky, impacts a lot of things, and didn’t add any value to our workflows. We preferred to make use of the audit log when weird things happened, and for the most part, tell people to do the right thing.
* Insist that workflows come from the teams. Individual teams were given a standard workflow when they started, but were encouraged to make it their own. Central management had to cope with what the individual teams wanted their workflows to be, and weren’t permitted to make them add statuses or transitions to make reporting easier. The only exception to this was around having to use a common set of resolution options.
* Open up the admin role to anyone who wanted it. If an IC or Team Lead wanted to make small changes to their team’s JIRA, they could just come sit with someone who knew how and work it out. If they wanted to make more significant ones, they received the 10-minute lecture covering the top five things that seem safe but will in reality break everyone’s JIRA setup, and then were given admin access to go do what they wanted.
In the end, some teams used a sophisticated ten-step workflow with granular transitions, and some used it as Trello – but they were all unified in one place, linkable and searchable, and had common support for discussion, auditing, and file management.
Re: Trello, “Jira Sucks”, and Tool Dysfunction
#55Earlier quoted context omitted.
I think people associate JIRA with middle managers who "work" all day in JIRA and foist draconian JIRA "processes" on everyone. eg: My current manager wants us update all open JIRA tickets every morning with "current status" . Not sure why manager types like JIRA though..
I hate JIRA, but I noticed something. If I tell people to do something, they won't do it. If I create a ticket in JIRA it has a much higher probability of getting done. It's not been too bad, after I got over the hate of not having real markdown and the 100 fields when a ticket is created that are mostly unused. I prefer little to no process, but the work has to be organized some how, and using git with emacs and org…
Not sure if you've seen the org JIRA integrations, but you can effectively do ticket management in org-mode.
Re: Trello, “Jira Sucks”, and Tool Dysfunction
#56I feel like a big part of people hating on JIRA is that it creates a formal process you have to follow - something enforced by code, and not just "always move your card to this Trello column first". It’s also so tempting for middle-managers to generate bogus reports, based on metrics that the people doing the work know don’t matter. Even with that, though, I haven’t found anything else as good for linking and organiz…
I'll add also to periodically figure out what works and doesn't work and why across the company and expand that institutional knowledge to the relevant stakeholders / documentation. Your JIRA flow should provide just a little bit of structure around your existing communication structure.
Re: Trello, “Jira Sucks”, and Tool Dysfunction
#57"Jira sucks" is not a useful thing to say. Yeah, Jira's default workflow isn't awesome. Yeah, it's a giant pain to configure an alternative workflow; and the learning curve to do so is ridiculously steep. Yeah, some BigCorps have configured painfully bureaucratic workflows in it. But you can also configure it with a very Trello-like workflow. Why would you use Jira with a Trello-like workflow instead of just using Tr…
I get why you're excited about this, but I think it's a mistake. One thing I've seen over and over is projects where everybody did their job and the project still failed. Why? Because everybody was put into silos. Each person could define success as doing what they were assigned. The developer built to the spec. The database person made the database work. The QA person verified that the system met the spec, and the o…
A siloed mindset doesn't come from giving people personalized views of their actionable work. And making those views available doesn't prevent people from opening the other views or seeing the big picture.
Our team works as a very unified team despite having the ability to pull up specialized views of their own work. Tools that prevent people from focusing in on their own work are no substitute for good communication.
Re: Trello, “Jira Sucks”, and Tool Dysfunction
#58Earlier quoted context omitted.
Not that I'm aware of. Most Jira shops I've worked in have disabled that field entirely.
Any good resources for convincing management that this is a useless practice with absolutely no benefit to real-world estimation or productivity?
Other than finding out about that practice in the interview stage and using it as a yellow flag suggesting that it might not be the job you want? Not really.
Either management understands software development or they don't, and it's not something you can really teach them either. I don't need my managers to know our stack or even be capable of developing working software themselves, but it's hard for someone who's never spent 6 months working in the coding trenches to understand the amount of uncertainty inherent in software development.
Re: Trello, “Jira Sucks”, and Tool Dysfunction
#59The biggest issues I have with JIRA have to do with it being one of the world's most inconsistent, unintuitive, and undiscoverable UX's possibly ever made. All manner of things are hidden in "..." menus, and any screen will have several such menus visible at once, but they're all different. It feels very much disjointed and like the UX is done in a deeply siloed process that considers only the most local region of th…
The thing about JIRA hate (or love), is that it only has a little to do with the actual product. As the article says, crappy process will give you a crappy experience. But a crappy configuration will do just the same. If you're constantly hunting behind menus to get to stuff it's likely that they've enforced some process on to you but not properly reconfigured the screens or transitions so that you get what you need…
> every complaint I've ever heard about JIRA could be remedied by a better implementation
Erm... what can't be fixed with better implementation?
My big point of hate on JIRA is how it uses some mutant hybrid of markdown and wiki text, so going between JIRA and Github is a nightmare of context switching. Can that be fixed with a better implementation, of course it could, but the point is Atlassian doesn't seem to think about UX.
Re: Trello, “Jira Sucks”, and Tool Dysfunction
#60There's just too much in JIRA to make it easy to use. If I need to ignore 80% of the fields and buttons to work with an application it's overengineered.