The bag and the kanban, part 1

You can view part 2 of this series here.

I have been exposed to a high level or radiations last Friday at Kaizenconf, where I was busy wrapping my head around the latest and greatest thoughts of our community.

In a particular session that morning, I was listening to Jef Newsom, who was trying to set up a small experiment about a new twist on the kanban pull system he had thought out. We were supposed to form a line and one by one, moving towards the right, fill up up the kanban board.

The idea behind this process was to focus on the personal goals of the users, as described by user stories.

Let me start by showing you what the kanban board looked like towards the end of the workshop. This is what had been setup on the wall:

 

The goal was given to us by Jef and written in the "Goal" square:

Elect the President

Not too bad, huh?

Our line was formed from a couple daring volunteers and we stood on the left side of the board. Every minute, we were supposed to move one square to the right and add a post-it note in that square, effectively pulling from one item in the previous square.

 

The Kanban

Here is a quick explanation of the board.

People

People in the system are protagonists (your typical users,) antagonists, benefactors and victims. Antagonists are people who might want to abuse the system. Benefactors are the users who will benefit from your application, and victims are those that might be hindered by it.

Going with our previous goal of electing the president, two post-it notes were placed rapidly in this square: Valery the voter as a protagonist, and a Presidential Candidate as a benefactor.

Personal goals

The personal goals of our people are basically user stories, written in the form of "To <why>, a <who> <what>."

For example: "To enter a sales order (why), a clerk (who) brings up the new sales order panel (what)." Boring, yes, but it shows who needs to do what in order to accomplish their personal goal.

As you might imagine, multiple user stories can be thought up per person and pretty soon, we had:

• To vote, a voter must submit a ballot
• To show a user that he/she has voted, a message will be displayed
• To make sure a voter can't vote more than once, something unique about them will be stored with their ballot
• To verify the result, an official will be able to create a paper trail

S.A.F.E. Scenarios

S.A.F.E. stands for Success, Advance, Fail and Error. Each of these types of scenarios describe what could happen to each personal goal in our kanban.

Let's take our first personal goal: "To vote, a voter must submit a ballot." We can determine the following scenarios:

Advance: The voter has successfully submitted a ballot. This type of scenario is what is required to happen in order to reach one or all of your success scenarios. They are consequently very important.

Success: All voters have successfully submitted ballots. These scenarios must happen in order to accomplish the goal "elect a president." Yes, they are also very important.

Error: It is not clear what a voter had in mind when he submitted his/her ballot. Data is missing. Errors slow you down. They are obstacles standing in the way to your success scenarios. You will have to find a way to deal with error scenarios to maximize your advance.

Fail: Ballots are lost. Ouch... the election must start over. You have failed. Game over!

Interactions

For each scenario described above, we then have to define one or more interactions in our kanban. This is where we finally get to be technical.

What objects are going to be used, created or destroyed? What kind of data are we dealing with? When does it get created? Where do we save it? Are there any relationships that we will created or modify? Any properties we need to keep track of?

Jef was pretty vague here, mentioning the methodology that HP uses to define interactions. I guess this section is up to you. I don't quite know yet how I would deal with it.

Test/Specs or UI

These two are in parallel. From the interactions you can write tests, spec out a design or sketch out your UI. Here again, you can insert your favorite methodology.

Code

And finally, you code! Take a test, a piece of UI or a spec and code it!

In retrospect

Something became clear very fast: the amount of information that is put into the kanban is exponential as you move to the right. Towards the end, we had one goal, two people, four or five personal goals, two or three SAFE scenarios for each one of those personal goals, etc.

What's more, when one of us got to the coding square and actually had to write some code, the whole line screeched to a halt because coding takes longer than coming up with the rest. Coders are the constraint of this system.

Take a look a what the board looked like at the end:

This is an unmanageable process without creating more rules to better run the kanban. Also, what happens if you re-prioritize personal goals? Well you would then have to restructure your S.A.F.E. scenarios, your interactions, your tests, your UI, clearly a complicated task.

It got me thinking... There's got to be a way to make this more efficient, at least in my IT environment. Could we separate this kanban in two? Can we have a backlog from which the developers can pull at their own pace while the users, managers and project leaders refine the backlog?

In the end, what I want to achieve is to protect the coder, our constraint, without restraining the creative juices that fill up the first half of the kanban.

I'll go into more details in my next post: The Bag and the Kanban, part 2.