4 ms·

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

by aantix 2y 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.

aquilaFiera 2y ago
+1. It's been 15 years since I used Tracker but I miss that aspect of it.
jadbox 2y ago
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.
cpeterso 2y ago
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/ 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.
teeray 2y ago
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.
- shagie 2y ago
  > 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 https://i.imgur.com/dQE9vWn.png and https://medium.com/@daitcheson/you-can-do-better-than-jira-1a84986facc5 https://medium.com/@daitcheson/you-can-do-better-than-jira-1...
  - hinkley 2y ago
    Your honor, he needed killin’.
  - theamk 2y ago
    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)
    - shagie 2y ago
      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.
  - Aeolun 2y ago
    That first one looks kind of reasonable compared to our ‘simplified’ workflow. The full one?…
- hinkley 2y ago
  That fucking state machine page makes me want to shoot someone.
- acdha 2y ago
dangus 2y ago
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.
- aantix 2y ago
  I hear Jira is the ultimate in flexibility and widely beloved. ;)
  - hinkley 2y ago
    That’s a paddlin’.
- necovek 2y ago
  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).
  - dangus 2y ago
    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.
dimal 2y ago
I was on one team that used it and it always felt overly simplistic. But I have to admit that we generally delivered what we committed to each sprint. It was pretty clear when we were overcommitting.
jumpei163 2y ago
Agreed, every time I clone an issue tracker or to-do list on the go, the first thing I do is deleting the "priority" column.

by aantix 2y ago

aquilaFiera 2y ago

+1. It's been 15 years since I used Tracker but I miss that aspect of it.

jadbox 2y ago

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.

cpeterso 2y ago

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/ 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.

teeray 2y ago

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.

shagie 2y ago
> 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 https://i.imgur.com/dQE9vWn.png and https://medium.com/@daitcheson/you-can-do-better-than-jira-1a84986facc5 https://medium.com/@daitcheson/you-can-do-better-than-jira-1...
- hinkley 2y ago
  Your honor, he needed killin’.
- theamk 2y ago
  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)
  - shagie 2y ago
    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.
- Aeolun 2y ago
  That first one looks kind of reasonable compared to our ‘simplified’ workflow. The full one?…
hinkley 2y ago
That fucking state machine page makes me want to shoot someone.
acdha 2y ago

dangus 2y ago

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.

aantix 2y ago
I hear Jira is the ultimate in flexibility and widely beloved. ;)
- hinkley 2y ago
  That’s a paddlin’.
necovek 2y ago
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).
- dangus 2y ago
  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.

dimal 2y ago

I was on one team that used it and it always felt overly simplistic. But I have to admit that we generally delivered what we committed to each sprint. It was pretty clear when we were overcommitting.

jumpei163 2y ago

Agreed, every time I clone an issue tracker or to-do list on the go, the first thing I do is deleting the "priority" column.