4 ms·

I always giggle when I look at the promo screenshot of fancy new to-do app that is supposed to solve the project management once and for all, and there are like

by dvh 6mo ago

I always giggle when I look at the promo screenshot of fancy new to-do app that is supposed to solve the project management once and for all, and there are like 6 items on it instead of 200.

alemwjsl 6mo ago
It also looks like Jira.
SOLAR_FIELDS 6mo ago
It’s simply very early on in the endless lifecycle of project management: Simple kanban is great! It’s simple! Okay, new users, new feature requests. Wow now I’ve got a really robust product but still it only solves problems for maybe 30% of people. Let’s add more! Eventually we have converged to Jira and instead of doing a few things really well we now do everything poorly. At this point you’ve probably got enough cargo culted corporate bureaucrats using your product to survive for quite awhile as you ride the wave of revenue into the slow tide of mediocrity. Then the death and rebirth as the new starry eyed project management tool begins as YetAnotherTrelloClone
- KronisLV 6mo ago
  > Eventually we have converged to Jira and instead of doing a few things really well we now do everything poorly. Is a system that does everything within its scope well not conceivable? If it is, does systems ending up like Jira come as a result of scope creep and gradual evolution (not designing the whole thing up front with its admittedly huge scope), not enough development effort or just wanting to ship things soon instead of spending 5 years making the damn thing be good? And then, how do we get there - a Jira killer, that’d be as good as Linux (or maybe BSD) is to OSes? It’s weird that project management has either small focused tools or big ones that are also bad in a variety of ways.
  - piva00 6mo ago
    A system that does too much is complex almost by definition, with complexity you introduce conflicts between features that need to be resolved through design, designing for multiple interactions of conflicting features is neigh impossible. The combinatorial of interactions between many features will inevitably create unresolvable edge-cases that need to be patched over, either hidden away or by tacking on more complexity so the user can control how these edge-cases should be solved for their own workflow. There is no way to do such design upfront, you can only upfront what you can think and reason about. That's how all projects start, and their demise is exactly from realising "oh, we don't cover this flow, maybe we should have a feature for that". Taking all these learnings and applying to a new system that has more design upfront starts to verge on Second System problem. Linux is also full of cruft, it's good enough but I don't think you should live with the impression that is a benchmark of software quality. It's still impressive but as any complex system it has many issues from legacy.
- post-it 6mo ago
  Tbf Jira is great, you just need a project manager with good opinions that sets it up and maintains it well. It turns out project management is a real skill and not a hat you put on the owner's less favourite sons.
  - eddyg 6mo ago
    Jira excels when there is a Jira governance committee comprised of people who actually understand data flow and are the only ones with admin privileges. Too often some manager asks for (and is given) admin access and starts “improving” things. Sure, anybody can create custom fields and screens and slap together a janky “workflow”, but well-oiled Jira Ops prevent an explosion of custom fields, they curate the create, browse and edit screens of each issue type to only show the fields that are important at that stage, use custom screens on workflow transitions along with validators and conditions to help ensure an issue is always in a reasonable state, etc. Then users don’t complain about the tooling. But Jira governance takes time, effort, discussions with stakeholders, etc. And without it Jira gets a bad rap.
    - themgt 6mo ago
      Jira excels when there is a Jira governance committee True but oversimplified. Without a Jira administrative state, along with of course democratically elected Jira executive and legislature and a duly appointed Jira Supreme Court, Jira governance committees over time tend to slide into self-dealing, tyranny and eventually mass executions of anti-Jira resistance factions. Sustaining Jira regime legitimacy over time is far more involved than simply a governance committee with its stakeholder discussions and five year plans for new custom fields.
      - sidewndr46 5mo ago
        Even when that happens, if you democratically elect a socialist governance committee you may suddenly find yourself liberated from your electoral duties by the USA
    - wombat-man 6mo ago
dzogchen 6mo ago
The best Kanban board is a physical one. You are also not going to be able to put 200 items on it. That’s a feature, not a bug.
- TipsForCanoes 6mo ago
  The fundamental idea behind Kanban was WIP Constraint Management. Unfortunately, so many people have been doing cargo-cult agile for so long that now the word "kanban" means 'task board with columns' to most people. It should not be possible to put 200 items into a column on a Kanban board unless the team is actually shown to have the capacity to work on them without causing a bottleneck.
  - okovooo 6mo ago
    "WIP" does not work - it only seems that you are in control of the process. It may work for the same type of tasks (hammering a nail), but in my practice, where all tasks are different, it did not work anywhere.
    - wpietri 6mo ago
      It has worked fine for me on a variety of software projects for more than 20 years. Here's a project I documented back in 2004, where we used physical cards: https://williampietri.com/writing/2004/teamroom/ https://williampietri.com/writing/2004/teamroom/ These days I'm on an all-remote team, and we use GitHub's kanban interface with WIP limits. That also works fine, and them main difference form how I worked back then is that we no longer do estimates. I'm not sure what went wrong for you, but my strong suggestion is not to think of it as a task board. Think of it as a board that lists units of value. E.g., features delivered, research completed, messes cleaned up. We do sometimes make task breakdowns for cards, but that happens as we start work on the card, and it's just a checklist somewhere (for us currently, in the GitHub issue via Markdown checklists). An important mindset shift for a lot of teams to use kanban boards well is to get away from siloing and toward collaboration. For my teams, cards were generally not individual achievements, but things we collaborated on. I think it's also important for software teams to have a BLOCKED column between TODO and WORKING. The only cards that should count against your WIP limit are the ones that people are truly working on that day. If there's something you can't work on for some external reason, move it to BLOCKED. Then before a card is taken from TODO, try getting any BLOCKED item going first. It's also worth talking in your retrospectives about common reasons things end up blocked, and I like to set a pretty low limit for blocked cards to force discussion. Happy to discuss further, but kanban approaches definitely work well for software.
polotics 6mo ago
..instead of 2000 ?
- dvh 6mo ago
  I meant for this week
lawgimenez 6mo ago
I remembered one project I added over 20 items and then GitHub’s Kanban started freaking out. Never did I used it since. Trello was great but got heavier too with all those fancy stuffs and colors. I’m still in the lookout for a great kanban software though.

by dvh 6mo ago

I always giggle when I look at the promo screenshot of fancy new to-do app that is supposed to solve the project management once and for all, and there are like 6 items on it instead of 200.

alemwjsl 6mo ago

It also looks like Jira.

SOLAR_FIELDS 6mo ago

It’s simply very early on in the endless lifecycle of project management: Simple kanban is great! It’s simple! Okay, new users, new feature requests. Wow now I’ve got a really robust product but still it only solves problems for maybe 30% of people. Let’s add more! Eventually we have converged to Jira and instead of doing a few things really well we now do everything poorly. At this point you’ve probably got enough cargo culted corporate bureaucrats using your product to survive for quite awhile as you ride the wave of revenue into the slow tide of mediocrity. Then the death and rebirth as the new starry eyed project management tool begins as YetAnotherTrelloClone

KronisLV 6mo ago
> Eventually we have converged to Jira and instead of doing a few things really well we now do everything poorly. Is a system that does everything within its scope well not conceivable? If it is, does systems ending up like Jira come as a result of scope creep and gradual evolution (not designing the whole thing up front with its admittedly huge scope), not enough development effort or just wanting to ship things soon instead of spending 5 years making the damn thing be good? And then, how do we get there - a Jira killer, that’d be as good as Linux (or maybe BSD) is to OSes? It’s weird that project management has either small focused tools or big ones that are also bad in a variety of ways.
- piva00 6mo ago
  A system that does too much is complex almost by definition, with complexity you introduce conflicts between features that need to be resolved through design, designing for multiple interactions of conflicting features is neigh impossible. The combinatorial of interactions between many features will inevitably create unresolvable edge-cases that need to be patched over, either hidden away or by tacking on more complexity so the user can control how these edge-cases should be solved for their own workflow. There is no way to do such design upfront, you can only upfront what you can think and reason about. That's how all projects start, and their demise is exactly from realising "oh, we don't cover this flow, maybe we should have a feature for that". Taking all these learnings and applying to a new system that has more design upfront starts to verge on Second System problem. Linux is also full of cruft, it's good enough but I don't think you should live with the impression that is a benchmark of software quality. It's still impressive but as any complex system it has many issues from legacy.
post-it 6mo ago
Tbf Jira is great, you just need a project manager with good opinions that sets it up and maintains it well. It turns out project management is a real skill and not a hat you put on the owner's less favourite sons.
- eddyg 6mo ago
  Jira excels when there is a Jira governance committee comprised of people who actually understand data flow and are the only ones with admin privileges. Too often some manager asks for (and is given) admin access and starts “improving” things. Sure, anybody can create custom fields and screens and slap together a janky “workflow”, but well-oiled Jira Ops prevent an explosion of custom fields, they curate the create, browse and edit screens of each issue type to only show the fields that are important at that stage, use custom screens on workflow transitions along with validators and conditions to help ensure an issue is always in a reasonable state, etc. Then users don’t complain about the tooling. But Jira governance takes time, effort, discussions with stakeholders, etc. And without it Jira gets a bad rap.
  - themgt 6mo ago
    Jira excels when there is a Jira governance committee True but oversimplified. Without a Jira administrative state, along with of course democratically elected Jira executive and legislature and a duly appointed Jira Supreme Court, Jira governance committees over time tend to slide into self-dealing, tyranny and eventually mass executions of anti-Jira resistance factions. Sustaining Jira regime legitimacy over time is far more involved than simply a governance committee with its stakeholder discussions and five year plans for new custom fields.
    - sidewndr46 5mo ago
      Even when that happens, if you democratically elect a socialist governance committee you may suddenly find yourself liberated from your electoral duties by the USA
  - wombat-man 6mo ago

dzogchen 6mo ago

The best Kanban board is a physical one. You are also not going to be able to put 200 items on it. That’s a feature, not a bug.

TipsForCanoes 6mo ago
The fundamental idea behind Kanban was WIP Constraint Management. Unfortunately, so many people have been doing cargo-cult agile for so long that now the word "kanban" means 'task board with columns' to most people. It should not be possible to put 200 items into a column on a Kanban board unless the team is actually shown to have the capacity to work on them without causing a bottleneck.
- okovooo 6mo ago
  "WIP" does not work - it only seems that you are in control of the process. It may work for the same type of tasks (hammering a nail), but in my practice, where all tasks are different, it did not work anywhere.
  - wpietri 6mo ago
    It has worked fine for me on a variety of software projects for more than 20 years. Here's a project I documented back in 2004, where we used physical cards: https://williampietri.com/writing/2004/teamroom/ https://williampietri.com/writing/2004/teamroom/ These days I'm on an all-remote team, and we use GitHub's kanban interface with WIP limits. That also works fine, and them main difference form how I worked back then is that we no longer do estimates. I'm not sure what went wrong for you, but my strong suggestion is not to think of it as a task board. Think of it as a board that lists units of value. E.g., features delivered, research completed, messes cleaned up. We do sometimes make task breakdowns for cards, but that happens as we start work on the card, and it's just a checklist somewhere (for us currently, in the GitHub issue via Markdown checklists). An important mindset shift for a lot of teams to use kanban boards well is to get away from siloing and toward collaboration. For my teams, cards were generally not individual achievements, but things we collaborated on. I think it's also important for software teams to have a BLOCKED column between TODO and WORKING. The only cards that should count against your WIP limit are the ones that people are truly working on that day. If there's something you can't work on for some external reason, move it to BLOCKED. Then before a card is taken from TODO, try getting any BLOCKED item going first. It's also worth talking in your retrospectives about common reasons things end up blocked, and I like to set a pretty low limit for blocked cards to force discussion. Happy to discuss further, but kanban approaches definitely work well for software.

polotics 6mo ago

..instead of 2000 ?

dvh 6mo ago
I meant for this week

lawgimenez 6mo ago

I remembered one project I added over 20 items and then GitHub’s Kanban started freaking out. Never did I used it since. Trello was great but got heavier too with all those fancy stuffs and colors. I’m still in the lookout for a great kanban software though.