Research on Multi-tasking

I came across an interesting article in Time magazine about multi-tasking. The bottom line is that we truly cannot multi-task, we can just switch from task to task, but at what price? According to the article

When people try to perform two or more related tasks either at the same time or alternating rapidly between them, errors go way up, and it takes far longer--often double the time or more--to get the jobs done than if they were done sequentially.

I know I've been making more effort to stop multi-tasking. One key for me to get something done is to shut off distractions; don't look at email, close out of IM, close the browser, so I can focus on the task at hand.

The article goes on to say a little stimulation can help but to much gets distracting. I like listening to traditional Jazz (no lyrics) when I'm trying to focus. Nothing like some good Coltrane to help get that spreadsheet done.

Another interesting fact, the mind needs quiet time in order to help memories form. Another reason for meditating. On the same line, it's important to get away from all the technology and have some interactions with people.

Everyone's out to teach you something

This idea comes from Don't Sweat the Small Stuff by Richard Carlson.

Imagine everyone is out to teach you something and it's your job to figure out what that something is. By taking this approach, you will become less annoyed with people. So that driver that cut you off is there to teach you to keep alert while on the road. That punk rocker with the pierced lip and eyebrow is there to teach you about not being judgmental. That end user that never seems satisfied is teaching you how to strive for the best product you can produce.

Next time someone has you frustrated or angry or impatient, figure out what they're trying to teach you and you'll find your frustration level go down. You'll start learning the things they're trying to teach you.

Retrospectives

Last week was the end of the first iteration on one of my projects. We had a review with the customer and then the project team held our retrospective. We really focused on 2 things; what did we do well that we want to continue doing and where can we improve for iteration 2.

I first learned about the concept of retrospectives after reading Norman Kerth's book Project Retrospectives: A Handbook for Team Reviews. You can also find more on his site, retrospectives.com.

To often I've been in organizations that pay tribute to the idea of "lessons learned" by holding a meeting after the project, writing some ideas down, and then forgetting about them when the next project starts. I've helped large, global organizations set up lessons learned databases so they can collect these lessons learned from project managers around the globe. None of this is any good without a key ingredient; changing people's behavior. Without that it's just a lesson documented.

I think agile principles really show the value of retrospectives. The retrospective isn't held after the project, it's held often, throughout the project so behavior can be changed immediately. After our meeting last week, we assigned a couple action items and we changed some of our patterns this week. Nothing major, just kaizen at its finest. In 3 weeks, at the end of the next iteration, we'll do it again.

Waterfall is Stupid

So I got to spend one day at the Scrum Gathering in Orlando this week. One of the keynote speakers was Dr Mark Paulk. Among other things, he led the effort to develop the CMM model for software at Carnegie Mellon University.

During his talk, Dr Paulk said "Waterfall is stupid." His point being that the waterfall approach is not an effective way to develop software.

I've had to "observe" the rest of the conference via my friend's twitter feeds and blog posts. Jesse Fewell has a day by day recap on his blog as does Dave Prior.

Space Shuttle Launch

OK, So I got to see the space shuttle launch tonight while I was here in Orlando for the Scrum Gathering. Pretty cool, even though I've seen them before. More amazing is meeting the rock stars of Agile project management that I've been reading about for years.

Where's the fire?

Seth Godin had an interesting blog post called How Far Away is your Emergency. His premise is that we don't address things until they become an emergency, but if we addressed them sooner, they would never become an emergency.

They say the best time to look for a job is when you don't need one. And the best time to invest in a new Purple Cow is when you're still milking the old one.

I had my first race of the season this past weekend, an off road duathlon. I didn't do bad, but it was a tough race. So now I have to think about how to train through March and April, so that when I get to some of the bigger races in the summer, I'm prepared for them. Trying to cram your training into the weeks before the race doesn't work, the emergency is to close.

So easy, a chimp can do it

BBC is running a story about a chimp that showed it knew how to plan for the future. Santino, a chimp in the Stockholm zoo, would gather stockpiles of stones every morning before the zoo opened so that he could later throw them at visitors.

Last night, while at the Kansas City PMI Chapter meeting, my table got into a discussion on the attributes of a PM. One person mentioned a PM is organized. When I added that a PM knows how to plan, they questioned if that was the same thing. I said no, you can be organized in the present but not know what you need to do in the future.

So is planning one of the things that sets a good project manager apart? I've been in organizations that reward the "firefighter" - the person that works really hard to solve a crisis. I've always thought that with better planning, some of these fires might be avoided.

On my current project, we had a risk identification meeting last week. That resulted in some additional plans that will hopefully prevent some issues down the road. So take it from a chimp, a little planning can be a good thing.