GTD: “Personal Kanban” – The PAIR System

In my Personal Kanban “Getting Started” post, you may have noticed the “PAIR System” in the mind map. You are probably wondering “what the hell is that? Did you make it up?!”

Yes, yes I did :P :)

While going over, and over, and over the processes in my mind, several stages started to emerge as logical “pull points” for processing my “Life” story cards.

Backlog

The backlog is basically a repository of stories that have yet to be completed. So when you have a bright idea or come up with something you want to achieve, it doesn’t go on a task list, the refrigerator or a post-it note stuck to your significant other’s forehead so you get reminded every time you see them. It goes in the backlog.

This is a standard part of most Kanban boards, of course you may want to set limits on this also. I personally prefer to just focus on keeping it lean and clearing out the crap, but avoid limits (who wants to limit their dreams etc?).

Before doing ANYTHING, we first pick the highest value item from the backlog.

Preparation

At this point we review the item of value that has been pulled from the backlog. We assess the kind of actions we will need to take to get the job done. This might include tasks like:

1. For us code-cutters: analysis of requirements, mockups, spikes. “What implementation routes could work here?”
2. Sending emails to confirm required information for third parties. “What do you need to get this job done?”
3. Researching information if moving into unknown territory (new ventures that you just want to try). “Where the hell do I begin with this?”

The idea here is not “big up front” work, but rather figuring out “the best way forward”. This is a different mindset. You are not looking to cover everything, but enough to get the job done.

You will be amazed how much time can be saved by spending anything from 2 minutes sending an email to an hour having a coding spike. External parties also appreciate the fact that you are trying to keep them productive also. I have had some really interesting replies from bank personnel etc. the amount of gratitude they have expressed has been surprisingly great. Help others to help you.

Action

At this stage, we have all the information gathered in Preparation, so what do we do? Action it of course! The focus of this stage is to produce high-quality output for implementation. This will mean things like (sticking with the three examples above – remember, keep the flow):

1. Producing high quality, readable, maintainable, tested code.
2. Draft emails to third parties, ensuring all required information is contained and it is quick and easy to read.
3. Detailed information gathering and analysis based on direction established in Preparation.

Implementation

This is what we were aiming for, actually getting the damn thing done. At this stage we are actually looking at “applying” the changes. Again, following on from previous examples:

1. Deploying/releasing a product, version or feature.
2. Await confirmation that third party has completed your instruction.
3. Produce reports, documentation or future stories based on research etc.

Review

And finally, the hunt for Kaizen. How did the story go? Could we have done it better. Here we analyse the process to see if there were are any opportunities to reduce/solve weak areas.

Archive

Once stories are completed and reviewed, they can simply go in the Archive for safe keeping. This is not really a “required” part of the process, but it can be great for retrospectives and later analysis.

Blocked Items

Now, process reviewed, this is where things can get interesting. What if something goes wrong with the implementation?

“Stopping the Line”

The Toyota Production System (TPS) makes a key point in it’s process:

Build a culture of stopping to fix problems, to get quality right from the first.

This may sound kind of obvious, but it often helps if you imagine the Toyota Production line at work (this is based on what I have read – I would LOVE to see this in action)..

• There are people, parts and machines everywhere. This thing is a behemoth of well-oiled machine.
• Everyone on the production line has a red cord that they can pull which will shut the entire thing down.
• If high standards of quality are not met, every person on the line has the power to stop it due to the “blocked” item.
• When the line is stopped, it literally STOPS. Everything shuts down, sirens go off, lights flash – you get the idea.
• Then, the system changes. It’s “all hands on deck” to fix the problem and establish why something went wrong.
• Changes to the working process are made to ensure that this kind of defect/blockage never happens again.
• The line is started and production continues.

Now, you are probably thinking “wow, that’s a bit excessive” right? Well, not really.

The whole reason the TPS is so successful is because it fosters and empowers social change. A blocked item is not “just a minor defect”, it’s a breakdown in quality. How can you say you have “high standards” if you do not treat ANY breakdown in quality the same?

Blocked Items and The PAIR System

The notion of a blocked item was a big part of the thought-process behind the PAIR system. Each of the phases are carefully selected because they each focus on a certain core skill-set:

• Preparation – The ability to analyse a problem and plan a appropriate course of action.
• Action – The ability to hone your working processes to produce high quality output.
• Implementation – The ability to take what you have have produced and create a smooth, efficient handover to others.
• Review – The ability to critically examine your own work, then adapt and improve as necessary. This process cannot really be “blocked” – but I would suggest that you ensure you review early while the story is still fresh in your head – so you may want to set up “Work in Progress” limits.

So the idea is, when a story is “blocked” – you do your absolute best to remove the blockage, detail why it happened and remove (or at least reduce) the change of it happening again.

So, lets think about this and how “blocking” might work in certain scenarios..

Cutting Code

• Preparation – Blocked due to insufficient requirements specs from the client.
• Action – Needing to clean up nasty legacy code that was buried in the system.
• Implementation – Broken build.

Third Party Requests

• Preparation - Lack of understanding of what you are trying to achieve. There may be a need here to do some brainstorming etc.
• Action – Need to gather information from other sources before being able to continue.
• Implementation – Information sent to third party is missing some required information.

Unknown Territory (New Ventures)

• Preparation – Similar to “Third Party Requests”, lack of understanding of why you are here and what you are trying to achieve. Get back the drawing board.
• Action – Lack of “domain knowledge” (i.e. you come across something that you need to understand, and wasn’t obvious in preparation).
• Implementation – It is actually more probable that the implementation step will involve the creation of new stories that are more focused. Therefore, it is unlikely blockages will occur at this stage.

Wrap Up

So, there it is. I have of course started using this system and will no doubt be blogging about how it is working out for me in the near future. I wanted to get the initial concept out early to see if others have any thoughts and/or can perhaps start making use of it themselves.

What are your thoughts on this process?