Comment by aantix 10 months ago
The thing that I always liked about Pivotal is that it was visibly obvious that there was only one queue.
It forced everyone to ruthlessly prioritize and make the hard decisions.
In this moment, do you want me working on this bug, or this new feature? You have to decide - you get one or the other.
It avoided the "Everything is a high priority" dilemma.
> Custom issue states are a special kind of hell in JIRA.
The nth circle of hell looks like a Jira workflow. https://i.imgur.com/dQE9vWn.png and https://medium.com/@daitcheson/you-can-do-better-than-jira-1...
For the article:
> Whilst I wouldn’t recommend remote team members having to endure a subpar experience, for example during the daily Kanban meeting, is that really a good reason to degrade the experience for the rest of the team, losing out on all the benefits that gathering around a physical board can bring?
Are they seriously proposing _physical kanban board_ as a viable alternative to JIRA? This got to be a joke, right?
(Checks post date, it's 2019... Ah, that explains it)
Worked with a manager who had a physical kanban board in a nearby vacant cube... and had a ip camera set up to it so that the business could go to the IP and see the board. When they had meetings, they'd have the business people on speaker phone and... honestly, we had trouble not laughing overhearing those meetings.
60% yes, but 40% no, because there was nothing after "accepted" - so no way to track "in production" and "validated with users", which are the most important states. You could abuse the earlier states to do that, but then you have trouble tracking internal acceptance. Ultimately, reality just has more significant states than Tracker recognised.
A model that has worked well for my teams is to track story/development state and deployment state separately.
They are fundamentally different things, and you cannot always infer one from the other.
- "Accepted" is the final state. Deployed to prod and verified. Story is finished and can be hidden from active view.
- "Delivered" is set by QA when they believe the changes are complete and correct, ready for deployment.
- "Finished" is set by the developer when they finish, push, and create the PR.
It happens sometimes that a Finished story is deployed to staging in integration build X, but then omitted from integration build X+1, for reasons unrelated to the quality of the changes. In this case the story stays Finished (or Delivered) and we set the @staging label when deploying X to staging, but clear it when deploying X+1.
This works really well, especially after writing some glue code to integrate Pivotal and GitHub and your build/deploy flows.
Yes - 100% of the people I saw be annoyed after switching to GitHub projects were the people whose projects were perennially late but also had a roughly 1:1 ratio of PM overhead rituals to actual work. I’ve come to think of it like giving a toddler TikTok – there’s a certain type of person who cannot resist thinking that one more workflow state / custom field will be the secret trick for productivity.
I LOVED Pivotal tracker for just this reason- it was way more focused. It was hands-down my favorite task tracker. Since most of my projects were code related, we eventually moved to Github Projects which is honestly very similar in being focused. The downside is that non-technical people may need to get a Github account, but it wasn't that much of an obstacle in practice.
An alternative to one big queue is a separate queue for each client (external customers, internal teams, the dev team's own tech debt, etc) as described in "JIT selection from independent streams: An alternative to the “big backlog” of work":
https://longform.asmartbear.com/jit-backlogs/
Each client manages their queue order, so the dev team just needs to focus on the head of each queue. (Of course, the dev team should also work with clients to clarify the requirements for the next few tasks in their queues so the head task will be shovel-ready). The dev team can then choose which queue heads to prioritize and maintain a balance, such as always have one tech debt task and X bug fix tasks in progress in addition to client work.
+1. It's been 15 years since I used Tracker but I miss that aspect of it.
That sounds more like a disastrous missing feature to me.
A good productivity tool doesn’t dictate how teams work.
I’d rather have a tool that’s more customizable.
I know managers love Jira — a poster child for customizability — esp product managers, but I have yet to meet a software engineer who does.
It simply slows everyone down, but when it's your only tool for tracking work, it's still better than nothing.
Now, the problem with Jira is not necessarily customizability but that it's dog slow, complex, integrations suck, and permissions system is chaotic. Still, I have yet to see fully customizable work tracking system that's better made than Jira.
But also, a fixed set of features does not force you to ascribe the same meaning to them like the authors intended: I've used "bug" tracking systems to manage large projects with great success (including big features, enhancements, but also big and small fixes).
Honestly this is a bit like saying that the dishwashers don’t like the food being served at the restaurant.
Project management software isn’t made for the benefit of engineers, that’s on purpose. The customer is the business, not the engineer who works there.
Any issues with the engineers have with workflow really aren’t the fault of the software, it’s the fault of the project managers/engineering managers’ configurations.
You can’t blame the company that makes the paint for the choice in paint color.
Personally I think the only way Jira has dropped the ball is on page load performance.
When I ask my Jira admins to enable a set of people to do something on a project, they struggle.
When I create a ticket and don't open it right away before the popup is gone, poof, it's gone into the depths of that project backlog.
If I want to create a multi-project board, oh, now tickets don't have the same statuses, set up a mapping first.
Or figuring out the artifical limits between epics, tickets and subtasks.
And slowness, don't get me started there.
Yes, just like you are blaming the paint shop for only having the basic colors, I too can blame the paint shop for having 1M green hues to choose from.
And yet every paint manufacturer has hundreds of swatches of various colors that their paint 'comes in', even though there is practically an infinite possibility of colors available.
I've seen many custom JIRA workflows, where you define specific states that can progress to other states. Nearly all of them, over time, were modified so that any state can move to any other state.
And if you engineers don't use the tool you provide, the data in it is useless. Engineers are typically very smart and will just twist any tool they don't like.
Declaration: In order to have accurate state between projects and bugs, everything needs to be tracked in JIRA.
Result: 70% of your Jira stories are now "This JIRA tracks an issue stored in the Github repo, see the repo for current status"
> I’d rather have a tool that’s more customizable.
You think you would, until you do, and by then it's too late.
It's important to have good processes, but the point of all those processes is to help you make things more efficiently. Anything that leads to you spending extra time serving the process directly reduces the amount of real work you can do.
> the point of all those processes is to help you make things more efficiently
I think this viewpoint -- that these processes somehow could increase efficiency if only they were good -- has a lot to do with why engineers dislike systems like Jira, because they will never see the increased efficiency they are looking for.
Let me restate it in a way that I think is a little more nuanced:
The point of systems/processes is to lessen the amount of inefficiency in a group of people working together as that group a) gets larger, and b) experiences turnover.
Nothing's ever going to be as efficient as a single engineer that can build everything with all the details in their head at that very moment. But there's a limitation on size of problems you can solve doing that! So many people working on large problems hate their processes, because each individual person is doing less than if they were in a tiny, stable team, and they can feel this, even if the organization is making great progress.
(And then, at the largest sizes of organization, it's almost impossible to stop the org from crumbling from the weight of its own complexity. People do spend an awful lot of effort trying, though).
I agree with all of that. I understand why there needs to be some kind of rigor applied or else you have a bunch of engineers running around like cats. I'm not saying we shouldn't have process.
But, I've also worked in shops so hidebound that the aim of the organization seemed to be to Follow The Process above all else. Didn't ship anything all quarter? Well, at least we Followed The Process! Customers are screaming? That sucks, but The Process doesn't accommodate their needs this quarter. Principal engineers are leaving? They just don't appreciate The Process!
In my experience, Jira seems to resonate with PMs who adore The Process for the sake of The Process. Lighter, more opinionated systems like Pivotal or Linear seem to help teams deliver features more quickly than teams using Jira to march in line with The Process.
I also loved that it was adamant about having specific, defined states with no customization. The issue is todo, in progress, done, delivered, accepted… that’s it. Custom issue states are a special kind of hell in JIRA.