Hacker News Reader

Comment by lucisferre | Hacker News Reader

This is neat, and I could see it potentially being a useful way to categorize and organize e-mail, though I personally find e-mail clients that allow for deferral/scheduling sufficient for my needs.

However this trend of using lean and Toyota production system terminology to sell stuff that has no real relationship to it is starting to get tired.

None of these card column systems has any real relationship to the Kanban process outside of the use of cards. The similarities tend to end at a completely superficial level.

https://en.wikipedia.org/wiki/Kanban

Rule #1 of Kanban is that it is a "pull" system. By design e-mail is push. It would also be difficult to limit work-in-progress here, which is another cornerstone feature of a Kanban system.

View on HN

The Kanban the author is using is "software development Kanban", not "lean manufacturing Kanban". There is a subtle but useful distinction. Most of the people who use TPS-derived methods in IT are actually using models that were adapted over time in software development lifecycles. The names are the same, but they're actually different processes. (I find this annoying too, I'm just giving context for why this is) A more accurate term for the author's board may be "Scrumban", but I'm not a Scrum or Agile expert by any means.

You can use e-mail as a sort-of pull-based JIT system. You're constantly getting new resources, but you can't necessarily use them all immediately or action them all at once. So you stage the work in planning, and "pull" work into "doing" when you're ready. The lifecycle continues until an item ends up "completed" and archived.

I don't think work-in-progress is all that difficult to manage with e-mail, as your e-mails are basically feature requests or alerts that lead to a story, and once the story is planned and ready for working, you can determine what a suitable work limit is. The author's e-mail model may need a bit of modifying to create actual stories rather than just tracking an e-mail, which may not be enough in itself to begin working on.

Work is still meant to be pulled in software development Kanban. WIP limits are still a key feature.

They are different processes because Kanban is not the process, it is the mechanism for displaying the work in progress.

>Rule #1 of Kanban is that it is a "pull" system. By design e-mail is push. It would also be difficult to limit work-in-progress here, which is another cornerstone feature of a Kanban system.

I was actually just thinking about this the other day. To rephrase it slightly, an email inbox is essentially an opt-out model. Any person anywhere can put something in your inbox, and after reviewing/getting sufficiently annoyed you can opt-out from receiving their emails (marking them as spam, forwarding to trash, etc.)

Personally I've been interested in seeing how an opt-in inbox model would perform. Every email goes to spam and/or a review bucket, and then once a week (or whenever you feel like it) the user can skim the bucket for emails from people/lists they actually want to see, and approve them. Follow up emails from those address can then go straight to the inbox with out need for review.

This might not work for every use case, but I suspect I'd like this for my personal email use. No matter how many times I unsubscribe from an email list or service, a new one takes its place without me signing up for it. I think I would find significant less frustration being able to opt-in vs opt-out.

Google Inbox basically does this automatically for me. It has learned which email addresses I correspond with for work and other important topics, which it pushes directly to my inbox. It also automatically bins other emails into categories such as forums, commercial promos, social (newsletters and what not), which arrive in a single bundle each morning or each Monday morning. These bundles can be opened to see individual emails or archived as a bundle with a single click.

Definitely feels like an opt-in experience to me, and far better than previous email solutions I used.

Well, just treat your current inbox as your review bucket; and create another tag "approved" as your approved things. Every day you review your incoming messages and tag it approved.

I’m glad you mentioned this. I worked on an email client like this for a bit, but I found email difficult to work with. Basically I wanted to be able to whitelist important senders and have those emails appear to my desktop, then the rest I could get to when I had time to open my inbox.

I know ahead of time who I want to be able to reach me immediately. My boss, his boss, my team and my girlfriend. Everyone else can wait.

> Rule #1 of Kanban is that it is a "pull" system. By design e-mail is push.

Mine isn't though.. emails just sit there (on the server or in the mbox) until I 'pull' (handle) them. =)

While it's clear that the WIP limit isn't featured, I can't clearly see the distinction between email being push and traditional Kanban being pull.

I think that the push and pull being different are being applied to different things. Work is pulled into the resource that does the work. The push aspect of email is more akin to orders for products, which even in traditional Kanban systems is based on external demand and not production capacity, so also push, in a sense.

So, for a pull model for email, how would that work? I’d log in and see a “give me a ready for work task” that would give me an email to triage?

Reply on news.ycombinator.com