My tinkering with kanban

This post briefly describes kanban in terms of personal planning and management, and then explains how I combined a kanban tool (Trello) with Google Sheets to give me an easy way to record the things I get done so I could review them and reflect on how I’ve been doing.

Not nearly enough about kanban

Kanban (“sign” or “billboard” in Japanese) began as a system for improving efficiency in manufacturing by making tasks and progress visible. Here’s a simplified kanban board:

A kanban board showing tasks in three groups: to do, in progress, and done.
A simplified kanban board from Wikimedia Commons

The “to do” column, sometimes called the backlog, shows all the tasks that need to be done. The next column is “in progress.” One rule of kanban is to limit the work-in-progress, because you can only do so many things in, say, a week. At the beginning of a work cycle, then, you move cards from “to do” to “in progress” based on your capacity. As tasks are done, you move them to the “done” column, and you’re now able to move another task from “to do” to “in progress.”

There’s a lot more to this, but since I’m not a manufacturing plant, for me it was extremely helpful to read Personal Kanban by Benson and Barry.

The following video explains kanban in terms of software development. You can cheat and watch just the segment from about the 1:00 mark to about the 2:15 mark; that’ll be plenty for this post’s purposes.

A kanban board to plan

I’d seen coworkers using Trello on projects at my last job, so I got myself a free account. Trello has three levels: a board (think of this as a high-level category), a list (a stage in progress), and a card (a specific task). The following image is a board I set up for a trip I’d like to take.

A kanban board made in Trello, with three lists labelled backlog, in progress, and done.Here’s the same board with some cards added.

A Trello board showing three tasks under backlong, and one task under in progress.At the beginning of this imaginary week, I looked at the backlog — the pool of all cards — and dragged the “check visa requirements” card to the “in progress” list.

In real life, I might set a work-in-progress limit of four cards, forcing myself to prioritize items from the backlog.

When I finish a task, I drag it to the “done” list. Over time, that’ll be a big list, and it’ll be hard for me to see what I did when. One recommendation from Personal Kanban is periodically to review your accomplishments and reflect on your process, which is harder with a constantly growing list.

Laziness, the road to efficiency

I knew I could create a spreadsheet to record those completed tasks somehow, but I didn’t want to be copying and pasting all the time.

So I poked around in IFTTT (“IF This Then That”) to see if I could create a little app to do the grunt work for me.

Of course I could. The start of an IFTTT app is the trigger, the thing that kicks off an action. In IFTTT, when Trello’s part of the trigger, you spell out which group of Trello boards, which individual board, and which list on that board you’re talking about, as you can see in the example on the right.

In other words, the trigger is “if I drop a card here…”

That’s the IF THIS. The THEN THAT is an action. Trello’s already set up to take action with Google sheets. In fact there were two or three, and one was “add a row to a spreadsheet.”

Details from IFTTT for adding a row to a spreadsheetClick the image on the right to see the default setup in IFTTT for adding a row to a spreadsheet based on a Trello card.

The format confused me quite a bit, and I had to play with it for a while to figure out what the options were, and which ones I needed. All those labels in the formatted row section, for example, are the names of fields used by Trello; you can pick from them to make column headings in Google Sheets.

What the action section of IFTTT is really asking is:

  • What sheet you want to add rows to?
  • What do you want to put into each row?
  • What’s the path to the sheet?
The action portion of an IFTTT app, which will create a new row in a spreadsheet when a Trello card is moved to the DONE list.
The actual “add this stuff in the new row” action I use.

I made a lot of practice cards, dragged them around, checked the results, moved columns in the sheet, and so forth.

What did I end up with? A spreadsheet cleverly named COMPLETED. In the “formatted row” section, you specify the names of the columns, and those names come from the field names in Trello.

I was interested in when a card moved to “done,” what board it was on, the card’s title (the short description on the Trello card), and the URL in case I ever wanted to see it again.

Strictly speaking I didn’t need to specify the done list, since the whole app is about cards that got moved to a done list, but I put it in in case I ever want to add other lists as well.

The results

If you don’t have a spreadsheet named COMPLETED, IFTTT will create one the first time the app gets fired. I made the sheet ahead of time and practiced with dummy data. That seemed a lot easier.

What does the record look like?

A Google sheet showing data imported from Trello via an app in IFTTTThe first five columns were spelled out in IFTTT. Because Trello’s timestamp (date) is so clumsy, with help from an online colleague I learned the formula you can see in the formula part, which parses the long-form date and turns it into a more searchable, sortable one.

Details on making it work

At the beginning of the month, I (try to) go to the spreadsheet and create my own monthly archive. I copy the completed items and paste them onto a new, month-labeled sheet. On the main sheet, I then hide the rows I’ve just copied, so I’m ready to start recording the new month’s completions.

Usually, looking at a month at a time is better for me. If I wanted a longer slice of time, I can unhide rows on the main page and look at whichever I want.

I haven’t figured out how to automatically insert my date-simplification formula mentioned earlier, so every now and again I visit the sheet and just copy the formula to rows that don’t yet have it.

I have half a dozen kanban boards — one for professional concerns, one for personal development, one for household items, and so on. It’s a way to compartmentalize things; it works for me. That’s why, in the BOARD column of my spreadsheet, I have conditional formatting that changes the color of a cell based on the name of the board it came from. It’s a little stunt that I like, and I can use those labels to filter the display as well.

 

Destinations and expectations

(This is my second post related to destination-dispatch elevators.
Here’s the first.)

“What IS this stuff?”

Having encountered the touchscreen call panels and the buttonless cars of the Hyatt Regency Vancouver, I tried to find out what this approach was, and why it was.

Image of a multistory building served by four elevators, with many people ready to board each elevator.
Example A: the way things were

The condensed version:

Destination dispatch systems (sometimes called, tellingly, destination management systems) assign passengers to particular elevator cars based on their destination rather than by when passengers entered the elevator lobby.

Example A, taken from an online course on DD, shows a standard elevator system: passengers are waiting in a building lobby served by four elevators. When one arrives, everyone who can will enter, guaranteeing a maximum number of stops.

What’s more, until people are inside the car and select a floor, nobody–except the individual passenger–knows who’s going where. Out of a dozen passengers, eight could all be going to the 11th floor, but they’ll have to stop at 3, 4, 7, and 8 along the way.

A multistory building showing elevators assigned to specific floors. If you're going to the 8th floor, you'll be assigned to elevator B or D.
Example B: a conventional destination system

In a “conventional destination system,” as shown in Example B, people first choose a floor, then get assigned to an elevator based on that choice.

If this example were the Hyatt, when I selected the sixth floor, I’d get assigned to elevator C. There’d be no point in boarding elevator A or B or D–at least on this trip, they wouldn’t be stopping on the sixth floor.

If you compare the images, the four elevators in example B make fewer stops total, for the same passengers, than the elevators in example A.

The first-time passenger wouldn’t know that, of course; she’s mainly concerned with getting to the sixth floor so likely isn’t pondering the rationale. Though if three other elevators arrive before elevator C does, she might start wondering why.

The reasons why

The goal is to move people through the building faster and use the elevators more efficiently. Here’s an example from a Thyssenkrupp fact sheet for one of their offerings:

A chart comparing traditional elevator operation with destination dispatch. Traditional could involve 15 stops. Destination dispatch might require only 4.
Traditional elevator operation on the left; destination dispatch on the right.

It took me a while to read the left-hand example: there are four people traveling to each floor; they are color-coded by floor. Take the elevator on the left, three people get on in the lobby. The yellow person gets off on the third floor; the dark-blue person on the fourth, and the light-blue person on the fifth. In the right-hand example, four light-blue people get on the second elevator and travel straight through to the fifth floor.

The more I read, the more complexity I found.

  • Types of buildings: how you apply destination dispatch is one thing for a hotel, another thing altogether for an office building. And in the latter case, do you have a lot of within-the-building traffic, like from the finance department to the sales department?
  • Types of access: you can combine destination dispatch with a security system. For an office building in lower Manhattan, employees of Lochaber Amalgamated might have floor access determined by function — if you’re not in IT, maybe you have to be escorted onto the 9th floor by someone who is.
  • Destination dispatch might allow you to have fewer elevators with the same level of service as a greater number of traditional-technology elevators.

What I’m thinking (now)

As Don Norman said of design, everything is a tradeoff. Because this is (relatively) new technology, I think most people aren’t accustomed to it, and as noted early, each morning during my three-day stay, I was surprised to step into the car and find no destination buttons whatsoever.

For my wife and her fellow conference attendees, the switch between two hotels where events took place meant they were regularly shifting between the Old Way and the New Way, elevatorially speaking.

Still, the initial learning curve is relatively low. Yes, you’ll be a bit pokey on your first few rides (“Oh, right, gotta choose my floor”), and especially in the lobby you’ll learn quickly not to jump into just any open elevator–because not only is this one not going to the tenth floor, once you’re inside there’s no way to make it go there.

The most striking drawback, I think, was the lack of status information for people waiting, especially during busy periods like lunchtime. I waited on the sixth floor with eight or ten people wanting to descend to the lobby. We heard elevator noise and even voices in the elevators, but we had no idea when our elevator would show up, nor where it was in the meantime.

It doesn’t take long to get impatient at that point and to lose faith in a newfangled system. Yes, this might be more expedient for the average passenger, but I’m not the average passenger — I’m just me, and I’m wondering when I’m going to get off this damned floor.

I don’t have any big conclusion. Ultimately I enjoyed this real-life user-interface experiment. It left me with more appreciation of what a challenge it can be, trying to make new technology work in the real world.