February 2010

23 February 2010

I finally finished the first Personal Kanban video. (There are way too many videos that never made it past the cutting room floor). This first one is a quick tutorial about prioritization.

Prioritization is often even more difficult and daunting as the tasks that confront you. A priority filter in your Personal Kanban helps you determine what tasks are ready in your queue, and the order of importance they should assume.

We want to work with people we like and respect on projects that are fulfilling.

Idealistic? Pedantic? Maybe.

Yesterday's post provides a few equations as to why this might make sense. But in reality, it's all risk mitigation. Regardless of how much a difficult project might pay, it's usually so painful to complete as to be self-negating.

I had a project with a large client a few years back that was so painful that my wife refuses to acknowledge that I ever got paid for it at all.

Why?

Because there's a time value of money which is well defined by economists. It looks something like this:

The idea that money available at the present time is worth more than the same amount in the future due to its potential earning capacity. This core principle of finance holds that, provided money can earn interest, any amount of money is worth more the sooner it is received.

So, it took soooooooooo long for me to get paid by my client that a combination of interest I was paying for a business line-of-credit and the fact that I wasn't able to invest that money when I made it, greatly reduced the actual value of what I was paid for the project.

Okay, that's all well and good, but I was still paid. Why does my wife not even recognize this as an event?

I think this is due to a psychological value of money or (PsVM).

You see, when you do a thing, your brain gets really happy when you are immediately rewarded for that thing. Beyond simply instant gratification, serotonin levels rise making you feel happier, more social, you digest your food better, just a load of good stuff. Why? Because immediate rewards, have a funny two-pronged effect. They make us calmer (not nervous) but simultaneously more excited (ready to invent, ready to take on new challenges).

So NOT getting a reward when it is expected for a job well done drastically decreases the value of the reward when it does come. The longer it takes, the more our brains disassociate it as a reward and make it an entitlement. And if someone HAS to give you something and they don't do it on time, you quickly become resentful because they are keeping you from something you are entitled to.

Getting something you are entitled to has zero psychological value because you were supposed to get it regardless. This is why pre-calculated cash bonuses have been shown to be lousy incentives to effect change in companies. The disassociation of the reward from the individual (through having to wait and having it be a systematic equation) makes the incentive a disincentive.

It's like telling someone what to get you for Christmas, having them order it, and then having it be backordered to March. It was never really a gift to begin with because you requested it, someone else merely paid for what you wanted. But then, you don't get it in time and by the time it arrives you say "finally."

Money Money Money Money

In the end, Money is an abstraction. A really important abstraction, but one nonetheless. We need to figure out, as people, as companies, as a society, what we really value and where money fits into that equation. It's clear that, as an abstraction, the value of money is different to every individual. To some people it's a toy to play with on the stock market or in Macau. To others it's security to hold and look at and smile. To others it is power to buy and sell whatever or whomever they wish. But the psychological component is clear.

So when weighing future projects or opportunities ask yourself where that psychological value of money fits for you.

15 February 2010

The Modus Cooperandi business plan for 2010 is very simple and very short. We want to work with people we like and respect on projects that are fulfilling. We've learned over the years a (sort of) simple equation:

Variables:

PYL - People you like

PYDL - People you dislike

PROJ - Projects

CT - Completion Time

AT - Acquisition Time

WA - Work to Acquire Project

T$ - Time it takes to get paid

A$ - Amount you get paid

PP - Pain to complete the Project

SC - Satisfaction of Completion

Projects with People You Like

PROJ (PYL) = AT + CT + WA + T$ + PP - A$ - SC

versus

Projects with People You Don't Like

PROJ (PYDL) = ATx2 + CTx2 + WA*4 + T$*4 + PP*6 - A$*2 - SC*0

The equations balance the work of acquiring and doing and administering a project. We have found that work with people you don't like is:

Harder to acquire

Takes longer to complete

Takes longer to acquire

Takes longer to get paid, and

Are painful to complete

but

You get paid more

but

By the time you get the money you have zero satisfaction in the project.

So this incredibly unscientific equation is saying, work is balanced by income and satisfaction. And we've found that the cost / benefit analysis of working with people we like so far and away outweighs the opportunity costs of making more money with unenjoyable people.

But it gets better. I think there’s a Time Value of Money and a Psychological Value of Money – which I’ll describe in my next post.

11 February 2010

This is a dangerous quote that can both note we as humans don’t get things right most of the time or to simply excuse bad planning. We do not want to create rigid plans filled with single points of failure and we do not want to just write-off planning in the first place.

When we do things, we set forth a story-line. It’s just like going to a movie. We don’t know how that story is going to play out. We don’t know what twists there will be in the plot. But we DO have a good idea of some basic parameters.

For example, you are usually pretty sure that in a science fiction movie set in deep space Spongebob won’t show up. If you are building a deck by hand in your workshop, you are usually sure that the deck won’t become contaminated with eColi. If you are writing software, you can be pretty sure that you will not be delayed by a shortage of asphalt.

So, projects have parameters that we can plan around. These plans are based on assumptions. The assumptions are usually based on guesses and desires. As the project unfolds, conditions usually change.

Below I present this slideshare about our project at the World Bank last year. Many of our major assumptions about the project were wrong – yet the project was successful. Tonianne and I took more than what we needed (extra pens, different sizes of paper, etc) even though we thought we were just building a simple team Personal Kanban.

We assumed we’d build on type of visual control and ended up using others. We had a deliverable that was pretty clear as well. Even the room was different than we’d planned for. But, in the end, flexibility and an eye on project goals over the plan won out.

02 February 2010

This talk goes through a project my team did in early 2007 that used a hybrid XP / Personal Kanban approach to managing a widely distributed team and what we learned in "the early days." Here is the write up from the SeaSPIN site.

February 2 Meeting

Construx Software, 10900 NE 8th St Suite 1350, Bellevue, WA

Food & networking from 5:45 to 6:45 (pizza, salad, soda )Announcements from 6:45 to 6:55Presentation from 6:55 to 7:55Doors close at 8:30

Personal Kanban and Kanban for Distributed Teamspresented by Jim Benson

Kanban is rapidly gaining popularity in software development. How are teams and programmers migrating from straight agile to Kanban, or to hybrids like Scrumban or Scrow? How has this worked in the past? How do distributed teams make this more challenging? How can managers and teams best apply these new methodologies?

Jim Benson describes introducing both Agile and Kanban to development teams, focusing on a team he led in 2007 which built a complex transportation management prototype using nascent technologies and a team of cowboys – none of whom had used agile or been particularly collaborative before. How did he do this?

The answer: Subversion!

Let Jim take you on a journey of mystery and intrigue as he tells you how he fooled a bunch of programming malcontents into being a Lean, collaborative, highly effective work force. It’s like the A-Team, but with Skype.