Analogy Archive

Agile Traffic Analogy

– December 3, 2010Posted in: Agile, Project Management

The post today was brought to you by… my hellish commute and those in the Washington DC metropolitan area who help create it. Thanks!

Today, I’m going describe Agile concepts by using my commute as the analogy.

Goal

During any given day, spend as much time working or at home and as little time commuting as possible.

I’ll write a User Story because I’m weird like that

As a project management advisor to a government PMO, I want to travel 55 miles in the shortest period of time so I can spend more of my life delivering value than wasting time sitting in traffic.

Predictive Approach

How long will it take to drive 55 miles to the office in the morning and 55 miles to my home in the evening? We’ve all had to estimate our commute time. Sucks, doesn’t it!? We’re all terrible at estimating. Why? Things change…constantly! You can spend as much time and energy as you want, trying to think of all of the possible scenarios. You can break your commute into “chunks” and estimate those. That could give you a better estimate, taking into account variances in each leg of the commute. But, until you get on the road and actually start your commute, you just don’t know. We’ve got weather we need to deal with. We’ve got that knucklehead in the far left lane, driving 10MPH under the posted speed limit (with his blinker on). We have to deal with the occasional traffic accident. Work on a project is no different. You can try to estimate your time, up front, but when something happens (notice I wrote WHEN not IF) your original estimate is going to be wrong. What are you going to do? Are you going to try to make up the lost time later in your commute? Is something else going to be sacrificed like hours of work or hours at home?

Do I personally think there is a more accurate way to estimate a commute, as the commute happens? Yes.

Adaptive Approach

This was my Adaptive commute this morning. My wife told me that the traffic report on the radio stated there was an accident 40 miles into my commute. Good to know, I thought. Information is good. Communications is good. So, did I change my estimate at that time. Nope! Why, you ask? I was armed with my handy Droid X. My Droid X has GPS and Google Maps with a traffic overlay. Now, I still broke my commute down into chunks. I still had the basis of estimate there. But, the magic happened after the commute began. I did see the traffic slow down (on the map) that my wife referred to. But, the radio was still reporting that the lanes were blocked. The map indicated that traffic was getting by slowly. Good to know I thought. Information is good. Communications is good. But now, I saw (on the map) that traffic was stopped much earlier and they were not saying anything on the radio traffic report. By the way, the radio station only reports the traffic every 10 minutes. By getting realtime feedback from the Droid, I was able to know when I was going to have take a different route, to bypass the delay. I took the next exit and my commute route and the map refreshed. I could see, by the map, where I could get back onto my original route. I actually arrived to the office, 20 minutes from my optimum commute time. If I had not had the Droid and the constant feedback about the traffic conditions, it would have added a hour.

I still lost 20 minutes. But that was unavoidable. But I think I minimized my delays by getting real-time feedback. I had opportunities to adjust my course based on information. I was able to adjust my commute estimate every minute, not every 10 or 20 minutes. If someone from the PMO had called me to ask when I was going to get to the office, at any time along my commute, I could have given them a pretty good estimate. But that telephone call isn’t necessary. Here comes the kicker. I share my location with Google Latitude. They can see where I am at any time.

Here are some things to think about for your next commute

Know where you are and where you want to go
Break your commute into chucks
Get traffic conditions as often as possible
Be prepared to change direction
Be prepared to reestimate your time of arrival, the closer you get to your destination
Give people a way to know your location so they don’t have to ask you every 5 minutes
Feedback is good
Information is good
Communications is good

Like the image? Find them at Pictofigo

Popularity: 1%

Tags: Agile, Analogy, Estimating, Waterfall

Project Voldemort

Derek Huether

– November 2, 2010Posted in: Project Management

Don’t be alarmed if you look at my LinkedIn profile or my professional site and don’t see who’s paying me or the project I’m working on. Don’t be alarmed if you read my posts or articles and notice the same. Many know, if you ask me the time, I’ll tell you how to build the clock. That is, I’ll give you all the details you never wanted to hear. Sadly, when I informed a few people that I was going to be writing an article for PM Network magazine, I was asked not to write anything disparaging about the program I’m advising. I was told it would bad if anything I said or wrote cast an unfavorable light on the project. The question is, would it be bad or me or bad for the program? How many of you out there in the industry have perfect projects, where nothing goes wrong? It is reality! We just learn as we go.

Being I’m only allowed to advise and not allowed to enforce, I have to walk a bit of a tightrope. Then again, I have a backlog of fodder I could write about. The fodder could actually have value to my readers. So, I will continue to write.

So, for you Harry Potter fans out there, I’ll be calling the program I’m advising “Project Voldemort”, the project “that-must-not-be-named”. As per requested, I’ve removed all references from anywhere I have control. It really doesn’t bother me. If the name doesn’t bring value, why use it?

Until a company contacts me, wanting me to write and talk about thing like those I post here on The Critical Path, pretend I’m a Muggle advising Project Voldemort.

Like the image? Find it at Pictofigo

Popularity: 1%

Tags: Analogy

Agile and American Football

Derek Huether

– October 28, 2010Posted in: Agile, Project Management

This post is about Agile, not football. I like to use analogies so please, please don’t crucify me!

The football analogy

In 1983, at Superbowl XVII, the Washington Redskins beat the Miami Dolphins. It was a game my wife, who was born in the Washington DC area, reminds me of every time the Washington Redskins play a game. Mind you, I’m usually not watching the games. I’m off pondering what I would do if zombies tried to storm our home. Do I have enough plywood and nails? Do we have enough ammunition? But I digress.

So, what was unique about this particular team that made them so successful? Was it their head coach, Joe Gibbs? Was it the coaching staff, the team, or all of the above? Was it a simple process or detailed approach? I guess if they knew what the magic formula was, they would have repeated the winning season over and over again. Unfortunately, life doesn’t work like that and neither do projects or football teams. The Washington Redskins have won only 2 Super Bowls since. Gibbs retired from the team. Then, over a decade later, Joe Gibbs returned to the team, determined to take them back to the Super Bowl. As part of his strategy, he hired Al Saunders as the offensive coordinator. What I found interesting was Al Saunders’ offensive playbook reportedly had approximately 700 pages of various plays. Seriously!? 700 pages! Why would you think detailing play scenarios ad nauseum in a 700 page playbook would give you better results than having the team follow a few basic rules and then empowering them to make decisions on the field?

PMI PMBOK

The PMI Project Management Body of Knowledge (PMBOK® Guide) Fourth Edition has 506 pages. Some look at it like a cryptic instructional manual to all thing project management. Some merely look at it as something to reference from time to time, when someone asks “well, what does the PMBOK say?” And some look at it as the obstacle between them and obtaining the PMP credential.

Now, I don’t think for a minute, if you try to follow the PMBOK to the letter, you are guaranteeing project success. That may be the reason you see “Expert Judgment” listed so many times in the inputs-outputs.

Agile Manifesto

4 things we come to value

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

12 principles we follow

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.

Which playbook would you rather follow?

Popularity: 1%

Tags: Agile, Analogy, PMP, Washington DC

The Funnel Effect and My Kanban

Derek Huether

– September 13, 2010Posted in: Agile, Kanban

GuyKawasaki tweeted about a really cool infographic on Alltop titled Why freeways come to a stop. I checked it out and what most interested me was the graphic The funnel effect (I circled it in red).

The funnel effect is a really good analogy of why you should limit your work in progress, like I do on my Personal Kanban. In the analogy, just the right amount of water can go through as fast as it’s put into the funnel. But add extra water to the funnel, and the whole thing backs up.

In reality, keeping focus on just the right amount of work can allow you to finish more than if you didn’t. Personally, I limit my work in progress to 3 items. I never thought it would have such a positive impact. So, what do you have to lose? Do you have a long list of to-do’s, doing a little here and doing a little there? Do you ever feel like you’re not actually getting anything done? Today, rather than trying to multitask, focus on just a few tasks until they are DONE. If you complete one task, you can add another to your focus list. Remember, 99% done is still not done. At the end of the day, you’ll feel a sense of accomplishment, preventing a traffic jam of work and actually getting stuff done.

Popularity: 3%

Tags: Agile, Analogy, GTD, Kanban

Warning – Use of PM Force Authorized

Derek Huether

– September 9, 2010Posted in: Project Management

We went to an airshow this last weekend. Being I was in the Marines some 20+ years ago and spent the best of my time in the air in a helicopter, it was like a trip down memory lane. I loved the smells and sounds of the flightline. I even got to walk onto a CH-53. It was the first time since May 09, 1990. But I digress.

Upon arriving at the airshow, I noticed a warning was painted on the flightline that made me clap my hands like a cymbal-banging monkey. My wife took a picture so I could somehow relate it to project management in a future blog post.

Here is my Project Management translation:

WARNING

Efficiently Managed Project

It is unacceptable to do work on this project without motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Principle 5 Agile Manifesto of 2001 – February 11-13

While on this project all team members and the work under their control are subject to refinement.

USE OF PROJECT MANAGEMENT FORCE AUTHORIZED

Popularity: 1%

Tags: Agile, Analogy, USMC