Rendered at 02:40:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ketzu 2 days ago [-]
In a team I worked, we had full control over how we wanted to use the board. But the senior people just refused to engage with it, as anything they did on the board would make them accountable.
My lesson: Boards can be awful and useless even without managers running them! :)
I've been using a simple, standalone kanban to manage my own tasks, though.
wpietri 2 days ago [-]
This is such an important lesson. To me so many things from the "agile" toolkit appear to fail in ways where people tend to blame the tools, but instead are exposing people/process problems. The intent was that organizations use the pain points to improve process and solve problems. But in my experience a lot of organizations would rather remain dysfunctional than work effectively, and so will then shift to tools that don't expose the problems.
grvdrm 14 hours ago [-]
Not just boards. I’ll argue any deliverable.
Part of what makes corp life so inefficient is that lack of unified approach.
Working with a company where many of C-suite folks operate in normal corp world: Office 365. Slides, spreadsheets, the currency of business.
Meanwhile the product team operates in JIRA and in Confluence. They communicate with each other in their respective preferred formats.
But imagine if CEO said something like: any deliverable of A,B,C types has to be Confluence. No exceptions. 3 strikes until you get a penalty.
Would that help?
vjvjvjvjghv 22 hours ago [-]
That’s one thing I hate at my company . Many teams run Jira with backlogs, burndowns and whatever. In theory all the info is right there. But the big guys can’t be bothered to use Jira so somebody has to spend hours and hours prepping PowerPoint slides with the info that’s in Jira.
SOLAR_FIELDS 2 days ago [-]
I just require PR's to have tickets attached or it fails CI and otherwise use LLM's to write analytics to track what people are doing these days. Asking devs to hold themselves accountable is an exercise in futility in my experience. In a world where you can do that, why even bother with tickets outside of planning the work done? Might as well just transcribe your standup and turn it into tickets that way too.
eterm 2 days ago [-]
If this will solve the problem with boards, you need to be able to answer 2 questions:
1. What does this do that Trello doesn't?
2. What does Trello do that this doesn't?
okovooo 1 days ago [-]
Trello does not work in Russia. You cannot install it on your server in the company's closed loop. There is no task number, there are no subtasks, you cannot see the progress of subtasks on the parent's board. There is no analytics. There is no page where you can view all the tasks that can be taken on. The service does not claim the laurels of solving all problems, but it is unique in its own way.
okovooo 4 days ago [-]
Usually, everything is set up "for the manager"—the way they prefer to view the project. As a result, a tool that is supposed to help the team becomes a burden. When you work across multiple teams, the constant filtering and scrolling turn into a nightmare. You waste your energy fighting the interface before you even start working.
I believe that one glance at the board should be enough to instantly see where we are, who is overloaded, and what is stuck.
That’s why I’m building ooko. To finally make the board a tool for the entire team.
darreninthenet 2 days ago [-]
A decent tool could surely define multiple different views of the same information?
okovooo 16 hours ago [-]
Let's say. But is it good for the team? At a daily meeting, the manager shows the screen of his board and I don't understand where my tasks are on it. I've made personal filters for myself, but it's always difficult to navigate quickly in a meeting when it comes to my field of work
bonesss 21 hours ago [-]
[Not affiliated:]
I have used JetBrains YouTrack in a number of scenarios for that specific ability, multiple simultaneous views/boards for various stakeholders and production pipelines (multi-org and multi-project).
I’d give it an independent recommendation in general, too, as the scripting/querying/commands make many tasks simple. You can tell it was built by programmers for programming project management, in the good way.
wpietri 2 days ago [-]
It could in theory, but purchasing decisions for tools like these are generally made by managers or executives, so they end up being optimized for what those people want. Or, more accurately, what they think they want.
dankons 1 days ago [-]
Plugging the same linear.app mentioned in a different comment -- switched a couple years ago (small team, fed up with general slowness and jank of Jira) and don't want to look back.
globular-toast 20 hours ago [-]
I got really frustrated with Jira in my company. Getting rid of it completely would have been too lofty a goal, so I looked into how they were using it. Turns out they were mostly just using it wrong. You can have multiple "views" of the same info. I ended up fixing the boards and it mostly works now. It's still crap for various reasons and massively bloated, of course.
tarr1124 2 days ago [-]
[dead]
dizhn 2 days ago [-]
Made me think of a non-tech manager I had once who when we presented the newly installed bug tracker (of which we had none prior) that said . "This is great. You don't expect ME to use it right?")
zeafoamrun 2 days ago [-]
I looked at some off the shelf task tracking and kanban packages and they didn't do quite what I wanted so I just vibe coded one up. We use it at home now.
My wife even made a special hidden mode for her game https://www.kanbanchaos.com so it can act as a frontend for our actual task tracker. Full taskception
AFF87 2 days ago [-]
"No sprints were completed in the making of this game."
Loving this. And the fact your wife also sells socks as merch of the game!
wpietri 2 days ago [-]
I think not having much documentation is fine, but please make the demo something where people can use it without logging in. E.g., they can click a button and just start messing with a demo project. Then you regularly reap the demo projects that haven't been used in the last 48 hours.
okovooo 2 days ago [-]
ooko.pro It's not just a demo, it's a working service and a lot of people use it every day. The presence of registration is both a necessity and a kind of barrier from disinterested users.
wpietri 1 days ago [-]
It's also a barrier to interested users. I'm one. I am currently using 3 kanban solutions for different needs. I'm always looking for better solutions, but I'm not going to invest much in something with no docs and one screenshot.
That said, your answer here tells me what I need to know about the product.
_the_inflator 2 days ago [-]
I like the guy’s stubbornness. We all have been there.
I understand his account as releasing daily frustration in a constructive way. We all hate/love Jira, Excel whatever but the alternatives are worse and instead of one bad solution 20 different perfect apps to use as a substitute won’t cut it.
We all are or have been there.
I like the guy. It is funny.
jaffa2 2 days ago [-]
What does this do? Do i need it? What was it about the managers running the boards that was hated? Why does this solve that issue? So many questions
_s_a_m_ 2 days ago [-]
Channeling Stroustrup: there are two types of project management tools, the ones everyone complains about and the ones nobody uses.
IshKebab 1 days ago [-]
Yeah that's one of those quotes that has done more harm than good. It's roughly equivalent to the fallacy of the grey - some things are crap so everything is equally crap.
In reality nobody (sane) would claim that Bugzilla is better than Phabricator for example. Some project management tools are better than others.
jjmarr 15 hours ago [-]
He's right, though. C++ exists because it was compatible with C code. Not having to rewrite into Java was a major advantage and justifies most of the terrible design decisions made as a result.
IshKebab 12 hours ago [-]
Interesting, I think you're interpreting the quote in a different way to me.
It it "People complain about C++ and not Foo because even though Foo is better, C++ had to be crap in order for people to use it."
Or "People complain about C++ and not Foo because although they are equally crap, nobody uses Foo so there's nobody to complain about it."
I always thought it was the latter. Unfortunately I can't find much more on where he actually said this than his own quotes page which also doesn't really clarify anything: https://www.stroustrup.com/quotes.html
jjmarr 10 hours ago [-]
Speaking as a C++ developer on GPUs, it's mostly the first.
There's so many problems that no other language has due to the backwards compatibility guarantees Bjarne made to get companies using the language.
For example, C guarantees ABI compatibility. Object files from an older compiler/standard can be linked with newer versions of the compiler/standard. This is great if you want to distribute a proprietary library to end-users without revealing source code (libcuda & legacy enterprise tools).
But this guarantee applied to C++ means a templated function in the standard library can almost never change the implementation.
As a result of extending the guarantee to templates, the C++ standard library must create new classes and functions then deprecate the old ones, meaning they can't do basic optimizations to older code. A big complaint is "too many ways to do the same thing".
Rust doesn't make this guarantee.
That allows them to make a cleaner language with less duplication, but mostly forces Rust crates to be open-source.
Nvidia shipping libcuda.so in Rust means having to upgrade Rust constantly and potentially forcing customers to, or releasing the CUDA source code which hurts their competitive advantage.
Bjarne could've designed a number of OOP languages in the 70s and 80s. Smalltalk, Eiffel, and Simula, were better languages. But he built C with classes which is the reason it's used today.
> but mostly forces Rust crates to be open-source.
In practice how many closed source C++ libraries are there? I can't recall using a single one despite working on many closed source C++ applications. I'm sure they exist but a closed source Rust crate could just do what many C++ libraries do anyway - wrap a C ABI with a thin open source Rust shim.
> which is the reason it's used today.
Obviously it helped that C++ was backwards compatible with C, but all of those languages you mentioned use garbage collection and need some kind of runtime so they were never in the running for a systems programming language like C++. (I know "systems programming" is ambiguous but you know what I mean...)
I totally agree that the requirement of backwards compatibility with C made C++ a lot shitter. The most obvious examples are the automatic type coersion and the insane type syntax.
_false 23 hours ago [-]
at least bugzilla is actively maintained. Abandonware over something Mozilla, Red Hat, Apache, GNOME, and KDE still run production workflows on isn't an obviously sane choice
IshKebab 19 hours ago [-]
Phabricator is maintained - it's just a community project called Phorge now.
ZpJuUuNaQ5 2 days ago [-]
1. "Hated how managers run boards", but there is absolutely no explanation on what this system does differently. How does it differ from the myriad of existing solutions?
2. Documentation is practically non-existent.
3. The code isn't event open-source, and the license prohibits modification and distribution. Come on, this is essentially a TODO app.
4. Demo requires a user to create a real account and use an email address...
5. Telegram channel appears to have some demo videos, but all posts are in Russian. Why?
I would say this is some sort of joke if I weren't familiar with this kind of mindset, but I don't understand what causes this.
mjburgess 2 days ago [-]
Inability to see that the perceived difficulty in using a system is due to your own mismatched mental-model/needs/scenario -- so inventing one which is overfit to your own needs/model at this specific moment, which fails to generalise and is eventually adapted overtime to more scenarios and becomes frustrating again.
The cause is lack of self-awareness.
okovooo 2 days ago [-]
I do the service alone in my free time. Documentation is my weak side, it takes time, desire and understanding of what should be there. I am from Russia and most of the users of the service are from Russia. This is the first time that so many non-Russian speaking users have signed up for ooko. Telegram has translation functionality, if anything.
kojeovo 2 days ago [-]
looks like it can be vibe coded in 6 hours tbh
pylotlight 2 days ago [-]
I was thinking same thing, very confused on how 'simple kanban 2000' takes 6 years?
dijit 1 days ago [-]
Simple things are usually hard to make in reality.
maxloh 2 days ago [-]
That is a really limiting license.
Per the LICENSE file:
Modification Ban: The User has no right to change, modify, decompile, disassemble or create derivative works based on the Program.
Distribution Ban: The User has no right to distribute the Program without the prior written permission of the Licensor.
gwerbin 2 days ago [-]
It's source-available proprietary software that happens to be distributed through NPM.
If this is source available then every website is source available.
reactordev 2 days ago [-]
But every website is source available. How else would you render it? Streaming PNGs?
efilife 1 days ago [-]
Am I crazy or is this not minified, but obfuscated to hide what the code does? Can't test right now
okovooo 2 days ago [-]
I can't afford a free license. I have no sponsors and have been unemployed for a year. It's rare for a free-source project to succeed, so I decided not to use a free license initially.
inlustra 2 days ago [-]
I find this response a little odd. Absolutely respect the work you’ve put in, but explaining that it doesn’t have a free license because you’ve been unemployed is just bad marketing.
“It doesn’t have a free license because I believe in the product and think it stands out enough to warrant people paying for it” is probably the route you want to go.
brazukadev 2 days ago [-]
> I find this response a little odd
You find honesty a little odd?
That's quite odd.
okovooo 2 days ago [-]
I'll think about your words, thank you.
pif 2 days ago [-]
I keep stating proudly to any team mate and any manager that I've never ever needed a board to know what I had to work on.
helloplanets 2 days ago [-]
Six years? I think you're not being candid.
Why is the landing page 100% gated behind a sign up form? Why is this on NPM to begin with? All around weird.
Could be a trojan horse. Just a heads up to anyone about to download this.
This does not help: "Task management service based on the Kanban methodology. Helps decompose the task pipeline and speeds up all stages of your work" Sounds 100% generated by AI tbh.
okovooo 2 days ago [-]
I do it alone in my free time. NPM is the easiest way to publish an application. You can install the app locally at your place. And there is also a TG channel, there are posts on the functionality for review.
helloplanets 2 days ago [-]
I'm supposed to just blindly boot it up on my computer, with the license explicitly banning decompiling and disassembling the code, so it could sensibly reviewed?
Can you see why I'd be concerned about that?
okovooo 2 days ago [-]
you can run it in a virtual machine. All the code is written in javascript, and you can study it without even decompiling it.
explodes 15 hours ago [-]
Virtual machines don't prevent data exfiltration. Auditing code before using it does. I'm with GP. I was going to use this for personal use until I noticed this problem.
TipsForCanoes 2 days ago [-]
Can you show the capacity and flow management parts?
okovooo 1 days ago [-]
The limit can be specified per board (process). This is my vision of an electronic kanban board. Perhaps in the future I will add an indication to the columns, but now I want to check my guesses.
esperent 2 days ago [-]
Is there a username and password for the demo?
okovooo 1 days ago [-]
Yes, registration is required. This is both a demo and a working service that is used by a dozen teams.
esperent 1 days ago [-]
So it's not a demo then.
It would help a lot of you added an actual demo. Or simply changed the wording to say "make a free account here to test it".
okovooo 15 hours ago [-]
Perhaps you're right and it's worth changing the wording. But those users who are not ready to register will not follow the link and I will not find out about them. And those who are ready will not pay attention to the wording of the link.
goopthink 2 days ago [-]
“I spent 6 years building my Kanban as I hated how managers run the boards”… only to discover that problem was the managers and workflows designed for their legibility (not engineers), not the technology or software itself, and that the tech itself could be rebuilt in a weekend nowadays?
orphereus 2 days ago [-]
The amount of comments shilling LLMs on HN is skyrocketing. Could be a recession indicator?
peacebeard 1 days ago [-]
They weren’t shilling at all, it was a passive statement of fact. In fact, they didn’t mention LLMs at all and a kanban board could be built in a weekend without one so it’s not even clear if your comment is on topic
stagezerowil 2 days ago [-]
I don't think people are "shilling" LLMs. They are new tools that are exciting.
pylotlight 2 days ago [-]
Hey everyone, look at the luddite.
firemelt 1 days ago [-]
why?
reactordev 2 days ago [-]
Claude could zero-shot this.
mfgadv99 2 days ago [-]
[flagged]
dvh 2 days 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.
SOLAR_FIELDS 2 days 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
post-it 2 days 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 2 days 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 2 days 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.
physicsguy 1 days ago [-]
My current company has company managed boards, 6000 devs and we have about 250 custom fields. I work in a research team and we only need Kanban and I can't change the issue type if something is created. Hell.
wombat-man 2 days ago [-]
Yeah, jira is very flexible. A well managed jira can be pretty great
SOLAR_FIELDS 1 days ago [-]
The great thing about Jira is that it can do anything. The problem with Jira is that it can do anything
darkteflon 1 days ago [-]
Notion: “Hold my beer.”
mock-possum 1 days ago [-]
> you just need a project manager
That’s the real trick.
ngrilly 2 days ago [-]
Jira's UX is crap. Try Linear.app, which is truly great software, equally appreciated by both software engineers and project/product managers using it.
post-it 2 days ago [-]
Is this an ad? I've never heard of this and the website tries really hard to be an Apple product launch instead of showing what the tool looks like with 200 tasks on the board.
SOLAR_FIELDS 2 days ago [-]
I've used it at previous places of work. It's nice. Snappier and better looking than Jira at least. One of the previous advantages of using it is that everything has a keyboard shortcut, so if you learned that you could be very efficient with it. Nowadays, however, when an LLM is shuffling my tickets around, that feature is kind of useless and I'd probably prefer Jira simply because they integrate with everything under the sun
ngrilly 2 days ago [-]
Not an ad at all. I've been using Linear for the past 4 years. Been using Jira, Trello, GitHub Issues, and other issue trackers before. Linear is simply incredibly better compared to Jira. I had tons of colleagues in my current team and former teams who were skeptical at first, tried it, and 2 weeks later wre saying they would never come back to Jira. I've seen many similar comments here on HN over the past few years.
Quarrelsome 2 days ago [-]
People can sell me layers ontop of JIRA but you can't position yourself to replace it, too much already integrates with JIRA and if you're not a startup then its a political cliff edge to try to make a case to replace JIRA.
janmikael 1 days ago [-]
[dead]
KronisLV 2 days 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 2 days 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.
dzogchen 2 days 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.
post-it 2 days ago [-]
Emergency Room staff are perfectly capable of putting 200+ items on a physical board. Not writing tasks down because it's too time consuming doesn't result in a more manageable workload of tasks, it results in people trying to remember and forgetting.
saltcured 1 days ago [-]
I'm just imagining the ER situational drama proceeding to "inform the county we are not receiving new ER patients, whiteboard is full" scenario...
wpietri 2 days ago [-]
Sorry, but I don't think that's correct.
One of the big benefits of a physical kanban board is that the limited space means people only write down the stuff they really care to keep track of. For me it has never resulted in people forgetting anything important. It means they don't write down the unimportant stuff.
It's possible that some people would write down a lot of trivia or fantasy features, especially to start. The best response to that is to let them write the cards and then sort them according to actual priorities. But I've never seen anybody persist in that behavior very long. If they do, I think it's a sign of organization problems that tools can at best mask, never fix.
I think this can also be true of virtual kanban boards (e.g., GitHub's kanban view) if you keep people focused on the kanban view. Then they learn to focus on what's being worked on and the near-term to-do list. You can have a backlog column and let people fill it up as much as they want, but as long as you groom the top 20 cards or so to be your actual current priorities, people eventually adapt.
runj__ 1 days ago [-]
For software development that's perfectly fine, and probably leads to less bloat etc., but in the example given it's an Emergency Room. "Make sure patent X gets operation Y" is a bit more important than "More rounded corners?". I know these are bad Kanban tasks but in some jobs you just aren't allowed to miss and just do the things "really care to keep track of". The other stuff is important too.
wpietri 1 days ago [-]
Your theory is that emergency room workers would think "make sure patient X gets operation Y" so unimportant that they'd just leave it off the board? I have more faith in them than that.
There is no job where all work is equally important, where all ideas are equally good. Even in emergency rooms, where triage is a vital concept. I think it's ok if finding a new poster for the break room gets dropped because there's too much work treating patients right now.
TipsForCanoes 2 days 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.
somat 1 days ago [-]
The fundamental idea behind Kanban is backpressure signaling for logistics.
If I understand it correctly it moves the signaling in-band so it can be handled at a locally distributed level, that is, each local parts consuming system is responsible for directly signaling it's upstream supplier to provide more parts and this is done by putting the signals on the parts bins or making the parts bins themself the signals.
I guess there is also that weird software logistics thing that appropriated the kanban term but because software logistics is very different from manufacturing logistics has little to do with actual kanban. shrugs. It's probably still a backpressure signaling thing however.
okovooo 2 days 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 2 days 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/
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.
okovooo 2 days ago [-]
I understand what you mean, but I think this is a self-deception of control. After thinking about it, I implemented WIP on the process (board), but only in the form of an "excess indicator".
TipsForCanoes 2 days ago [-]
> "WIP" does not work
Such a bold statement when you must know that countless people have a very different experience. Kanban the team methodology is about process efficiency and avoiding bottlenecks.
WIP limits are triggers to redirect resources to the bottleneck is that causes the pileup. Example: If there is pileup of PRs needing review, that is the trigger for devs on the team to stop making new PRs and switch to doing reviews.
Kanban is certainly not the best methodology for all team tasks but where it fits it works very well.
Sadly, for a lot of teams "we are doing kanban" means nothing more than "we are using a task board with columns" or worse "we have no constraints or flow controls and do everything ad hoc."
okovooo 1 days ago [-]
Yes, many people disagree with me. Take this as an assumption that I'm checking in my service. Of course, it is necessary to limit the amount of work, but in my opinion, WIP per column does not work. Therefore, I have implemented limits only for the entire kanban board (process).
TipsForCanoes 17 hours ago [-]
I'm curious exactly what you found not to work. How was your manager using the WIP constraints and triggers, that you didn't like?
I ask because in my experience the main 2 reasons are either a manager who doesn't understand the kanban methodology and uses it incorrectly or that it simply doesn't benefit the workload of the team trying to use it.
okovooo 13 hours ago [-]
In recent years, I've been working in 2-4 teams at the same time. Each team has its own manager, and every year one or two teams changed managers for different reasons. This gave me the opportunity to work with different people, but not a single case of successful introduction of WIP limits. It's not because someone didn't understand how to work with WIP. It just didn't have a permanent effect.
For a change, it's worth trying different tools, I think it's useful for a good atmosphere in the team.
TipsForCanoes 9 hours ago [-]
Could you do me a favor and just explain what you found not to work?
lawgimenez 2 days 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.
alemwjsl 2 days ago [-]
It also looks like Jira.
polotics 2 days ago [-]
..instead of 2000 ?
dvh 2 days ago [-]
I meant for this week
Stevvo 2 days ago [-]
If you really did spend 6 years building this, then it's an excellent example of why you should be vibe coding instead; I don't see anything here that could not be made in 6 minutes instead of 6 years.
okovooo 1 days ago [-]
Using vibe coding, you will not be able to do such a service in such a short time. In addition to the goal of researching my kanban vision, I also experimented with an architecture that allowed me to achieve the required productivity and ease of development. AI is not that cool yet
subwatch_dev 2 days ago [-]
Six years of sticking with one product is the hardest part of solo building. Most of us (myself included) struggle with the opposite problem — shipping too many things and not going deep enough on any of them.
The convergence-to-Jira pattern mentioned in another comment is real, but I think the answer isn't "don't add features" — it's "add features for a narrower audience." A Kanban for 3-person dev teams will always beat a Kanban for everyone.
Curious about your distribution strategy. After 6 years, what's actually working for getting users — SEO, word of mouth, communities?
okovooo 1 days ago [-]
It takes most of the time to decide what to do next. I don't have so much energy and desire to do anything to try to do everything. The main way of promotion is advertising in search results. For me, it is the most effective and affordable in terms of quality for new users.
My lesson: Boards can be awful and useless even without managers running them! :)
I've been using a simple, standalone kanban to manage my own tasks, though.
Part of what makes corp life so inefficient is that lack of unified approach.
Working with a company where many of C-suite folks operate in normal corp world: Office 365. Slides, spreadsheets, the currency of business.
Meanwhile the product team operates in JIRA and in Confluence. They communicate with each other in their respective preferred formats.
But imagine if CEO said something like: any deliverable of A,B,C types has to be Confluence. No exceptions. 3 strikes until you get a penalty.
Would that help?
1. What does this do that Trello doesn't?
2. What does Trello do that this doesn't?
I have used JetBrains YouTrack in a number of scenarios for that specific ability, multiple simultaneous views/boards for various stakeholders and production pipelines (multi-org and multi-project).
I’d give it an independent recommendation in general, too, as the scripting/querying/commands make many tasks simple. You can tell it was built by programmers for programming project management, in the good way.
My wife even made a special hidden mode for her game https://www.kanbanchaos.com so it can act as a frontend for our actual task tracker. Full taskception
That said, your answer here tells me what I need to know about the product.
I understand his account as releasing daily frustration in a constructive way. We all hate/love Jira, Excel whatever but the alternatives are worse and instead of one bad solution 20 different perfect apps to use as a substitute won’t cut it.
We all are or have been there.
I like the guy. It is funny.
In reality nobody (sane) would claim that Bugzilla is better than Phabricator for example. Some project management tools are better than others.
It it "People complain about C++ and not Foo because even though Foo is better, C++ had to be crap in order for people to use it."
Or "People complain about C++ and not Foo because although they are equally crap, nobody uses Foo so there's nobody to complain about it."
I always thought it was the latter. Unfortunately I can't find much more on where he actually said this than his own quotes page which also doesn't really clarify anything: https://www.stroustrup.com/quotes.html
There's so many problems that no other language has due to the backwards compatibility guarantees Bjarne made to get companies using the language.
For example, C guarantees ABI compatibility. Object files from an older compiler/standard can be linked with newer versions of the compiler/standard. This is great if you want to distribute a proprietary library to end-users without revealing source code (libcuda & legacy enterprise tools).
But this guarantee applied to C++ means a templated function in the standard library can almost never change the implementation.
As a result of extending the guarantee to templates, the C++ standard library must create new classes and functions then deprecate the old ones, meaning they can't do basic optimizations to older code. A big complaint is "too many ways to do the same thing".
Rust doesn't make this guarantee.
That allows them to make a cleaner language with less duplication, but mostly forces Rust crates to be open-source.
Nvidia shipping libcuda.so in Rust means having to upgrade Rust constantly and potentially forcing customers to, or releasing the CUDA source code which hurts their competitive advantage.
Bjarne could've designed a number of OOP languages in the 70s and 80s. Smalltalk, Eiffel, and Simula, were better languages. But he built C with classes which is the reason it's used today.
It actually doesn't. There's nothing in the standard about it; it's up to compilers. See https://stackoverflow.com/questions/46746878/is-it-safe-to-l...
> but mostly forces Rust crates to be open-source.
In practice how many closed source C++ libraries are there? I can't recall using a single one despite working on many closed source C++ applications. I'm sure they exist but a closed source Rust crate could just do what many C++ libraries do anyway - wrap a C ABI with a thin open source Rust shim.
> which is the reason it's used today.
Obviously it helped that C++ was backwards compatible with C, but all of those languages you mentioned use garbage collection and need some kind of runtime so they were never in the running for a systems programming language like C++. (I know "systems programming" is ambiguous but you know what I mean...)
I totally agree that the requirement of backwards compatibility with C made C++ a lot shitter. The most obvious examples are the automatic type coersion and the insane type syntax.
I would say this is some sort of joke if I weren't familiar with this kind of mindset, but I don't understand what causes this.
The cause is lack of self-awareness.
Per the LICENSE file:
If this is source available then every website is source available.
“It doesn’t have a free license because I believe in the product and think it stands out enough to warrant people paying for it” is probably the route you want to go.
You find honesty a little odd?
That's quite odd.
Why is the landing page 100% gated behind a sign up form? Why is this on NPM to begin with? All around weird.
Could be a trojan horse. Just a heads up to anyone about to download this.
This does not help: "Task management service based on the Kanban methodology. Helps decompose the task pipeline and speeds up all stages of your work" Sounds 100% generated by AI tbh.
Can you see why I'd be concerned about that?
It would help a lot of you added an actual demo. Or simply changed the wording to say "make a free account here to test it".
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
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.
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.
That’s the real trick.
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.
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.
That’s a feature, not a bug.
One of the big benefits of a physical kanban board is that the limited space means people only write down the stuff they really care to keep track of. For me it has never resulted in people forgetting anything important. It means they don't write down the unimportant stuff.
It's possible that some people would write down a lot of trivia or fantasy features, especially to start. The best response to that is to let them write the cards and then sort them according to actual priorities. But I've never seen anybody persist in that behavior very long. If they do, I think it's a sign of organization problems that tools can at best mask, never fix.
I think this can also be true of virtual kanban boards (e.g., GitHub's kanban view) if you keep people focused on the kanban view. Then they learn to focus on what's being worked on and the near-term to-do list. You can have a backlog column and let people fill it up as much as they want, but as long as you groom the top 20 cards or so to be your actual current priorities, people eventually adapt.
There is no job where all work is equally important, where all ideas are equally good. Even in emergency rooms, where triage is a vital concept. I think it's ok if finding a new poster for the break room gets dropped because there's too much work treating patients right now.
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.
If I understand it correctly it moves the signaling in-band so it can be handled at a locally distributed level, that is, each local parts consuming system is responsible for directly signaling it's upstream supplier to provide more parts and this is done by putting the signals on the parts bins or making the parts bins themself the signals.
I guess there is also that weird software logistics thing that appropriated the kanban term but because software logistics is very different from manufacturing logistics has little to do with actual kanban. shrugs. It's probably still a backpressure signaling thing however.
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.
Such a bold statement when you must know that countless people have a very different experience. Kanban the team methodology is about process efficiency and avoiding bottlenecks.
WIP limits are triggers to redirect resources to the bottleneck is that causes the pileup. Example: If there is pileup of PRs needing review, that is the trigger for devs on the team to stop making new PRs and switch to doing reviews.
Kanban is certainly not the best methodology for all team tasks but where it fits it works very well.
Sadly, for a lot of teams "we are doing kanban" means nothing more than "we are using a task board with columns" or worse "we have no constraints or flow controls and do everything ad hoc."
I ask because in my experience the main 2 reasons are either a manager who doesn't understand the kanban methodology and uses it incorrectly or that it simply doesn't benefit the workload of the team trying to use it.
I’m still in the lookout for a great kanban software though.
The convergence-to-Jira pattern mentioned in another comment is real, but I think the answer isn't "don't add features" — it's "add features for a narrower audience." A Kanban for 3-person dev teams will always beat a Kanban for everyone.
Curious about your distribution strategy. After 6 years, what's actually working for getting users — SEO, word of mouth, communities?