I spent 6 years building my Kanban as I hated how managers run the boards
npmjs.com
npmjs.com
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 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?
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
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.
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.
That said, your answer here tells me what I need to know about the product.
I started doing this project when a new manager joined the team. And his first decision was to change the processes by rebuilding the kanban board. The team as a whole was initially satisfied with the board, which had been built for a long time with the previous two managers. Everyone began to propose their requirements for the kanban board, but the new manager did not hesitate to do as he saw fit. And in the future, this story was repeated with new managers.
If you take into account all the wishes, then the board becomes very large, both in width and in height. That's why I don't criticize new managers. In many ways, this is a consequence of the tracker's functionality.
Different types of work have different stages. For example, a developer needs a "code review" column, someone needs an additional "approval" column, etc. My idea was to give each type of work its own board. And on the task card, display which subtasks are currently being worked on. As a result, we would have unloaded the main kanban board, and the kanban boards for work tasks would have become more flexible.
It also provides new opportunities for analytics. Or here is the flexibility in creating tasks, for example, add an "analytics" task at the testing stage. For me, ooko is an experiment with a hierarchy of tasks, so what the pros or cons are remains to be seen. Something like that
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.
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.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
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.
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.
That’s a feature, not a bug.
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.
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 don't know what that means in relation to the Kanban methodology.
What I'm looking for is something like, "my manager attempted to improve our cycle time by introducing limits on the number of tasks that can be in each state on our board. When a limit is exceeded, we are expected to take a predefined action to help clear the bottleneck that caused the pile up. It doesn't work and we still have bottlenecks and have not improved cycle time or efficiency."
If all your manager is doing is putting arbitrarily limits on WIP columns, that's unlikely to accomplish much and thats not Kanban. This kind of limit is only beneficial for the person who starts too many tasks without finishing them. The Kanban methodology is about team efficiency, not individual task limits.
edit: typos
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.
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.
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?