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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
> Do you seriously blame the death star technicians? The cooks at the death star canteen? I find that extremely hard to understand.
You must be working very hard to not understand that, as it's very simple. They signed up for a job on a thing called the Death Star. Its only job is to commit genocide at a planetary scale.
They are morally responsible for the consequences of their choices. We all are. Getting paid doesn't negate that. If anything, it amplifies it.
You are confusing pointing out that people are morally responsible for the their actions with suggesting "that someone should leave their job on ideological grounds".
I get that you (and most of them) want to cash the checks without feeling responsible. Tough. People make the choice to work there, and they make the choice every day to keep working there. Other people get to make choices too, including about how they think about, describe, and treat people who profit from harming others.
Freedom of speech and freedom of action does not include freedom from consequences. Your freedom, or that of people making bank at Meta, is not more important than anybody else's freedom.
For those interested in a keep-everything-hot approach like this, it's worth checking out the 25-year-old library Prevayler. Full ACID guarantees, and radically faster than a database. I happily used it for a project forever ago and was disappointed to see it so thoroughly ignored.
Right? I'll often structure interview questions like this. I give a basic problem, hoping for a basic answer. Then I add complexity, seeing how they respond.
In my experience, it's much easier to train somebody on how to scale a basic system up in response to need than it is to get somebody who favors complexity to cut it back.
reply