My tinkering with kanban

June 26, 2019June 26, 2019 ~ Dave Ferguson

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.

Here’s the same board with some cards added.

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.”

Click 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?

The 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.

Signing on for user support

February 5, 2019June 12, 2019 ~ Dave ~ 2 Comments

Earlier this week, with tax time approaching, I went to a former employer’s website to download a tax form for the pension I receive. Since I only go to their site once a year, I wasn’t surprised that my password needed to be reset.

I was surprised how picky they were about resetting.

Fifty-plus words in the guidelines, and I still failed the first attempt — probably because the new password my password-manager software generated was too long. I cranked down 1Password‘s default of 20 characters, then failed again from not noticing the begin-and-end-with-a-letter part. Finally, I managed to enter a password GE could live with.

On the same screen , I saw they wanted contact information. Here too they provided highly specific guidance that managed not to guide that well.

What is with those min/max phone number fields?

Diminished as it is, GE’s a global company, with roughly 100,000 employees in the US, and more than 260,000 American retirees. Bump those up by, say, 10% to include Canadians, and you’ve got 400,000 people whose phone numbers, mobile or land line, fit the North American pattern of 987-654-3210.

And if I have to enter a minimum of 3 and a maximum of 3, you could just say “3 digits.” Why I have the option for zero digits in the second field passes my understanding.

You won’t be surprised to learn I wasn’t able to automatically go to the second field after entering three digits in the first. Nor was I able to tab–I had to click.

The phone business was a detour on my update journey, as it is here. I’d meant to update my email. That’s where GE shifted from guidelines to just plain nitpicking.

As soon as I started typing in the “confirm” box, the red finger-wagging appears to make sure I knew the two versions of my email address didn’t (yet) match.

I didn’t include it in the screen shot, but the Send button, which probably had a much more technoid label than “Send,” remains inactive until the two versions of the email match — so it’s not possible to submit ones that aren’t a match.

And when they did, I got this:

I think it’s great to have some confirmation that a process has begun. It’s not nearly as great when there’s no clear message to say the process had ended.

Granted, the first sentence below the heading says the password “will be reset immediately.” But I came to this sequence after entering my old password, which is a good suggestion that I had something I wanted to do, and it probably wasn’t resetting the password.

In other words, the Identity Manager interrupted me, dragged me into this administrative chore, and has left me here wondering how to get my tax form. There’s nowhere on this screen I could click to get me there; I’m stranded on Identity Island. I have to close the browser and start over.

So that’s what I did.

Luckily for me, 1Password worked the way I expected, filling in the new password.

I made my way to the tax information screen and clicked on the helpful link to view or print my 1099 form. Good thing I knew that 1099 was the form I wanted.

And this was the result:

Passing by “maintainance” as alternative spelling for maintenance, take a look at the time window… and the time.

I’m in the Pacific time zone, so for me the maintenance window would have been 2:00 – 6:00 pm. I saw this message at 6:59 am. Maybe the maintenance took longer than expected. Or started sooner.

This might seem like a lot of grousing about relatively minor setbacks. The unfortunate part is that the experience suggests a stronger focus on the system and its requirements — or preferences — than on employees or retirees and their wishes.

I’ll bet GE has a good idea how many times a year people need to reset their passwords. A little data collection might even reveal patterns about what people did after resetting, emphasizing that resetting is probably not a primary task for people using this site.

Making practical use of that information isn’t flashy, like responsive web design or roller-towel pages, but it’s a solid move toward user support, especially in this kind of I-don’t-come-here-often setting.

Show what you know (the Building Job Aids edition)

October 4, 2015 ~ Dave ~ 1 Comment

In my Building Job Aids workshop (presented last Tuesday at DevLearn 2015), participants analyze multiple case studies, applying techniques and using job aids to, well, build job aids. Among the skills they practice are the ability to choose the right type of job aid for a task, and the ability to use that type effectively.

There’s a lot of thinking and writing: I make an effort to avoid explaining much before an exercise. Instead, there’s a minimal introduction, with a lot of what would have been explained turned into a print resource to be consulted as needed.

One potential downside is that especially an hour or so after lunch, thinking and writing are conducive to dozing off.

At the same time, my assumption was that participants would want and need additional practice on relevant examples. How could I give someone the chance to assess different job aids and rate their effectiveness? Did she think the samples would produce the desired result? How did they align with ideas in our workshop?

The challenge wasn’t so much finding the examples as structuring the evaluation. The tradeoffs I saw (or believe now that I saw):

Time constraints
Relevance
My desire for multiple elements in a rating system
My desire for a simple, overall total

Then the format presented itself in three words:

bja best in show

I liked this title so much, I was determined to use it. But I’ve learned not to be literal about this kind of borrowing. What makes Jeopardy!-style games in training a dumb idea (even a counterproductive one) so often is not (necessarily) Jeopardy! itself. It’s the mismatch between the content and a format best suited to recalling isolated facts.

Some characteristics of dog shows that I thought suited my goals: I had widely different types of job aids, like the different dog breeds. I had limited time, which at least for me was like the dog-judging segment where the trainer fast-walks the dog in a set pattern before the judge. Plus judging.

That’s where I had the most trouble. How to get multiple points, an overall total per judge, and a logistically sane process? I started with a three item scale, rating each job aid on its fit (is this a good job aid for this kind of task?), its function (is it likely to produce the desired result?), and its format (how does it stack up against the job aid guidelines in the workshop).

I could score each of those from 1 to 3, with an extra point thrown in for personal preference. No matter how I squinted, though, it looked like way too much math.

best in show single Then I remembered the Apgar score – a quick assessment of a baby at birth. Five qualities like heart rate or respiration are each assigned a score of 0, 1, or 2. The total describes the baby’s physical condition on a scale of 0 – 10.

So I came up with a five-point scale for Best In Show:

Aptness: how well the job aid fit the task and the setting
Payoff: how likely it’ll achieve the desired result
Guidelines: how it fit with guidelines in general and for its particular type of job aid
Appearance: overall effectiveness of the design
Response: the judge’s own reaction to the job aid.

As you can see, each item had a line for its score, with a box on top for the total.

In the interest of time, I limited myself to six competitors. This was the score sheet:

best in show 3 x 2 — (Click to enlarge in a new window)

Off to the show

I was pretty sure I’d have a decent internet connection. I made a slide with links to my six examples. I explained the scoring, distributed the ballots, and showed each competitor for 30 – 60 seconds, with some contextual commentary as needed.

If I’d had a large group, my plan was for each person to fold the completed ballot between the six boxes, so as to tear it into six individual sheets. I’d have had one person total the ballots for competitor A, one for B, and so on. My workshop group was small enough that I could divide a sheet of flipchart paper in six as Voting Headquarters. It was little trouble for me write down scores by candidate and then total them.

How it went

Best in Show was a success, both as a change of pace and as an exercise in judging job aids. It also broadened exposure: half the competitors were new; the other half had been seen only briefly, as examples, earlier in the day.

An unexpected plus: everyone could see all the individual totals. One job aid received solid 10s except from one person who rated it a 7. Another participant said to her, “I want to know why you rated it a 7.” The question was not a challenge but rather genuine interest in how another person applied the principles of the workshop.

Aftermath

Thomas the corgi (with the kind permission of Jane Bozarth) — Thomas the corgi, showing his best
(with the kind permission of Jane Bozarth)

I’m really pleased this went as well as it did. I’m thinking of ways to make it work better (one participant was confused by my instructions and rated on a scale of 1 to 3 rather than zero to 2).

And if I have more time, I’ll have a follow-on exercise: Raise the Runt. The idea would be to see which job aid scored the lowest, and then talk about why and about how to improve it.

Working out loud, 42 days in

June 19, 2015 ~ Dave

Lots of people in my extended network have been working out loud — sharing what they do, and the thought process behind it — long before #WOL as a term got very far down the street. This informal reflection (often followed by informal exchange) has made a tremendous difference in how I learn things and how I get better at things.

If you’re not familiar with the idea, for starters there’s John Stepper’s book, and there’s Jane Bozarth’s Show Your Work. In both cases the emphasis is not simply on what gets done, but how it gets done.

Before the week’s over, I wanted to go out loud with a small item that’s produced a lot of progress for me in the past six weeks. I’d like to have something more obviously impressive, but I’m going with “personally worthwhile.” I can’t find the original source — most likely because it’s buried in the cognitive junk drawer of my Twitter favorites. But the idea is this:

If you’ve got some future goal — say, you’re giving a presentation in four months — there’s research to suggest that framing your goal in days, rather than weeks or months, is a much more effective way of spurring yourself on.

Try it yourself: which has more psychological weight? “I’ve got three months” or “I’ve got 91 days.”

The notion intrigued me, and with not much searching I found the Countdown Widget at the Google Play store.

The day I installed it was four months ahead of the target I’d set for myself. But the widget counts down in days — so it displayed 120 on my phone.

As you can see in the screen shot I took this morning, that’s now down to 78. I’ve got work to do this weekend.

I made sure to put the widget on the home page, and so every time I glance at my phone, I’ve got a double reminder of the schedule I chose: the number of days appears, and the bright ring around the number disappears, bit by bit, with each passing day.

What this has done for me is probably what end-of-the-day reflection does for other people, or a carefully tended to-do list: I look at this and ask myself what I can do next to move forward toward my goal.

Another out-loud angle: I talked about this with a co-worker, and at least three times a week she’ll notice the countdown on my phone and ask what I’ve done on my project lately.

Excelling at assembly, or, vats improvement

November 20, 2014November 22, 2014 ~ Dave

In a previous post, I showed a fictionalized example of an actual guide for assembling a piece of industrial equipment. These instructions weren’t particularly well done, and I set myself the task of making some improvements. I also wanted to explain what I did, and why I thought it was an improvement.

The original, written on seventeen sheets in an Excel workbook, had more than 50 steps. I didn’t fictionalize them all, and I haven’t tried to revise them all. I’ve done two pages (that cover what 5 of the original pages did). I think these revisions are representative. (You can click each image to open a full-sized version in another window.)

By the way: I don’t have any documentation other than what’s in the original widget vat instructions. In some places, I’ve made an educated guess about details that aren’t clear; in other cases I made things up. I’ll point these out along the way.

On to the revision!

Why my version looks this way

We’re guiding a task that’s mainly a procedure: a sequence of steps that follow one another logically, with relatively little decision-making.

I see this as a job aid for lots of reasons, including the large number of steps. A number of my revisions are part of what any good job aid should include.

A clear title

The original read “Main Assembly Instructions,” which is ambiguous at best, unless Quasimodo Corporation only assembles one thing.

Here I’m pretending that there are several models of widget vats that differ mainly in size. I’ve put the model numbers into the title so the assemblers can tell easily if these are the instructions they want.

First things first: safety and prerequisites

Every page of the original version had a box listing the same three pieces of safety equipment–as if the developer thought the assemblers might take off their safety glasses between pages 11 and 12.

I’m also pretending that the “submittal drawing” spells out things like how many fasteners you need of each type. If that were not the case, I’d have to find out from my client whether (for example) the fasteners were stored at the assembly point, and if so how the workers could get more when they needed.

Emphasizing what’s important

The original version didn’t make much effective use of contrast, alignment, or spacing, so it’s much harder to figure out what’s important. That’s one reason I’m a fan of language like “before you begin.” In my revision, that stands on its own as the header for a number of items that we want the worker to do before starting the assembly.

And rather than the original’s unfortunate use of ALL CAPS, I recommend using capitals, boldface, or similar techniques in specific, limited circumstances. One of those circumstances is to highlight words like DO NOT, EXCEPT, DANGER, and so on.

Don’t confuse people with detail

Although the original used over 50 photos, in my revision I’ve hardly used any. In part that’s because I didn’t have good replacements for the photos–but also because many of the original photos fail to contribute useful guidance.

One problem with the original images–and with photos in general–is that they often provide too much detail, making it hard to grasp what’s important in a particular step. Or they ignore context, also making it hard to grasp what’s important.

Take a look at these three examples on one page of the original (click to enlarge):

Drawbacks to these:

Left: Why do I need to see a picture of the parts cart? The instructions say it’s important to push rather than pull the cart–but they don’t say if there’s a specific end I should push from. If there is, show it. If there isn’t, spell that out.
Center: you might be able to figure out, after studying this picture, that you’re viewing the assembly area from the side–but you can’t tell whether the top of the assembled widget will be on the left or the right.
Right: the instructions tell you:
- CHOCK ONE (1) WHEEL ON EACH END OF EACH VAT ASSEMBLY FIXTURE (FOUR (4) CHOCKS TOTAL).
- In my first revision, I’d missed the “four chocks total” part, which implies that neither the all-caps approach nor the FOUR (4) text/numeral approach helped.

Although I didn’t have much to work with, I have a couple of examples of images I think would work better.

The top picture in “image detail” shows a closeup helpful for one assembly step: the flanges should face up, and they should face out from each other.

(Yes, I made up the term “bleem flange.”)

The lower picture is a line drawing rather than a photo. Line drawings are a great way to eliminate unnecessary detail. I’ve teried to reduce details to the essentials: you’re fastening two (more-or-less) L-shaped pieces together, and you fasten through holes that alternate large/small/large/small.

(I’ve made the assumption here that the assembler should alternate directions when fastening these things: one fastener from one side, the next from the opposite side. If it were important to do that alternating while fastening, I’d add a box to spell that out. If you can install all the fasteners from one side, and then from the other, I’d spell that out. )

Some problems in the original version stem from the decision to always use three photos per page in the original. That’s a lot like deciding that you need to use one semicolon per paragraph: not wrong, exactly, but needlessly specific.

What I’d do instead:

Leave out the cart photo. My assumption: the assemblers know what the parts cart looks like. If they don’t, they shouldn’t be assembling widget vats.
Possibly include a close-up of the portion of the cart that I’m supposed to push, assuming there’s some sort of handle or push plate.
Use a bird’s-eye-view line drawing to show the layout of the assembly area.
- In the text for this step in my revision, I made up some floor guidelines to show “top” and “bottom” of the assembled widget.
- I also made up guidelines on the frame to show where to place some of the initial pieces.
Clarify where to place the wheel chocks.
- Chock one wheel of each assembly fixture.
  - Written this way, it doesn’t matter how many fixtures you have, so you don’t need the FOUR (4) business so beloved by people writing procurement specs.
- Place the chock so it’s closer to the center of the fixture than the wheel it’s touching. (If this is a best practice; I have no idea.)

Trying to build a useful set of performance guides like this can be a tool for analysis tool as well. You can’t create a successful guide without knowing what the inputs are, what the process is, what the outputs are, and what the standards for success are.

How many assembly fixtures do I need? On the framework, which side represents the top of the assembled piece? Can I install 20 fasteners in one direction, all in a row, and then 20 in the other? And what the hell is a “submittal drawing,” let alone the cryptic “BOM?”

What’s more, you can identify items that don’t need to be in the guide. Frankly, I think it’s…perhaps less than helpful to list “vat part cart” as an assembly aid. That’s like saying, “In order to build your IKEA Poang chair, buy the Poang chair and bring it home.”

The changes here, and the reasons behind them, apply to most performance guides like this. In my next widget vat post, I’ll show some revisions I’d make that are specific to procedural or step-by-step job aids like these instructions.

Dave's Whiteboard

Dave Ferguson's interests, ideas, notions, tangents

Improving performance