The last couple years I've been prototyping a not-for-profit pinball museum in Chicago. In the coming weeks we'll be opening 7 days a week in a 2900 sq ft space in the Loop: https://theflip.museum/
It's my first time starting a physical, retail business and it has been quite an education in the small details.
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.
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.
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.
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.
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.
> 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.
I read that as being his emotional reaction, not something he'd say in an interview context. This being an internet forum and all.
What I think he's sincere about is not wanting to work at a place that builds unnecessary stuff. And if people are asking for answers that require building unnecessary stuff, I think it's a reasonable inference that the place is not right for him.
I think interviewing is always a two-way street. If I got the feel that a place was going to have a lot of over-complicated code for me to deal with, or expected a lot of status-driven deference against actual user and business need, I wouldn't just give an interview-ending tart reply. But I would politely finish out the interview and then write them off unless there were other signals that redeemed the bad interview questions.
When I ask an interviewee a technical question, what I want is an answer that is correct technically.
If I want them to give me a different kind of technical answer, then I think it's on me to ask a question that actually requires what I'm looking for. It's not hard! All the Stripe interviewer had to say is, "Ok, great. It sounds like you have a good sense for system capacity. Now let's add another zero to all the load numbers." And then keep increasing orders of magnitude until they learn what they're looking to learn.
I am, just to be clear, not defending people being willfully obtuse or contrary jackasses. But that's not the scenario being described in either the Stripe story or the Google Sheets story I'm responding to. Two apparently reasonable people were asked technical questions and they gave answers that were the right thing for the business.
I think that's good and I like to hire people like that. I get lots of others don't, and I get the POSIWID reasons behind it. But I'm not going to pretend I think it's a healthy way to run an organization. And I also get that the people who like pretense and deference in interviews are not going to like me saying so. ¯\_(ツ)_/¯
Agreed. To me that's related to the question of minions vs professionals.
If I go to a doctor and say, "Hey, please prescribe me a lot of morphine," the answer will be some version of "hell no". That's because doctors, even if you pay for the visit, have responsibilities to the patient, the profession, and society at large. Responsibilities that should not be overridden by money or power.
The same is true for actual engineers, like the ones that build bridges. But although we often call ourselves engineers, a lot of us don't act like it. We're often more like the minions in a supervillain's volcano lair: whatever the boss says, we do.
We could, as a profession, agree to follow those. We could build an organization that supports people who do the right thing in the face of managerial pressure. We could censure those who don't. I'd love to see it happen, but I'm not going to hold my breath.
To rethink hiring, you have to spend some time understanding why most hiring is terrible both in terms of candidate experience and actual result. In my view so much of both hiring and general business operations is about managerial status and ego. https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...
Humans are primates, and primate dominance dynamics are going to be the default absent some conscious choice otherwise. Our whole executive/worker dichotomy is a descendant of the British class system. (E.g., note that airlines specifically have a "business class".) And MBA-driven business culture is focused on short-term managerial interest, not societal value or long-term business success.
I think all of those tendencies come to the fore at any organization that doesn't have either a strong sense of mission or a sufficiently desperate need for success that they pay attention to material reality rather than social reality. With a possible partial exception for things like co-ops and other places where the culture is fundamentally different enough. E.g., Mondragon, or Zingerman's.
I think Google, back in its don't be evil/organize the world's information era, probably qualified. They started with a very strong mission-driven culture rooted in academics and engineering. It took a fair bit of time for MBA dogmas to make it like most other places. But from everything I hear, what once felt almost like a calling now is just another job.
> Although it was originally intended to be cash it actually now is used as a "store of wealth"
It's also terrible at that. Bitcoin is down by something like half off its peak. The odds of me losing money to "government intervention" if I'm not actively criming, are quite low. Certainly well under 50%.
> Bitcoin works because you can technically have your wealth memorized.
If you are having to reach for increasingly absurd fantasy scenarios to justify something that was supposed to have thoroughly quotidian users, maybe you should take that as a sign?
> because you have ideas which they do not agree with
Oh, that's who's using bitcoin the most? Philosophers and the like? I had no idea.
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.
> yes you might be right but you also understand what the point of the interview is
To make the interviewer feel smart and powerful? To hire people who will do the thing the boss wants whether or not it makes sense? To find people who will overdesign things to maximize resume impact and the ability of their bosses to talk about what sophisticated systems they're running and for which they therefore need a much bigger budget?
It's my first time starting a physical, retail business and it has been quite an education in the small details.