PMO Analogy

As my tenure with the PMO comes to an end, I've had an opportunity to reflect on the last two and a half years.  What I realized was how much the PMO was like the U.S. Congress.  If I imagine the organizational structure of the PMO I've been supporting, I can imagine the CIO as the President and the PMO Program Director as the Speaker of the House or the Senate Majority Leader.  Beneath the Program Director are the Division Directors (Committee Chairs) and then members of the PMO (Congress in general).  What I've found interesting is many (not all) have their own agendas and motives.  Gridlock, not collaboration, is the norm.  Now, am I talking about the PMO or Congress?  I'm not trying to paint the PMO or Congress in an unfavorable light.  To the contrary, these people are all SMEs in their respective areas.  But they've seemed to have forgotten the common goal.  They've forgotten who the customer is.  In both cases, it's the American people. From my perspective, when you're trying to deliver value, you need to consider all of the options, regardless of your convictions.  I was the sole Agile evangelist in the PMO.  Think of me as a lobbyist representing the American people.  I did what I could to help the Government understand and to be receptive to new ideas.  But what the PMO failed to grasp was Agile is much more than a way to deliver software products.

I think Michele Sliger put it very well:

Being agile means that teams are working in ways that allow for change in order to better work together and provide a more useful and meaningful product to the customer.

My final days with the PMO will be like a long retrospective.  What went well during this engagement? What could be improved in the next engagement?

HT: Michele Sliger

Filthy Fishbowl

I read a really great post over at Mike Cottmeyer's Leading Agile blog.  To paraphrase, he wrote about his son having a fishbowl that was in desperate need of cleaning. He described the situation as

this poor little goldfish was swimming literally in it’s own filth. The water was yellowish brown and just gross.

Mike went on to use the fishbowl as an analogy, to write about an Agile adoption and transformation client. He wrote that it’s easy from an outsiders point of view to see what’s going on, but the folks inside a company have a difficult time seeing how they can transform their environment. The challenge is that sometimes there is so much that has to change to get healthy, it’s difficult to figure out where to start.  If you are that little fish, swimming around in that filthy bowl, how do you even begin to see what can be done about it?  Have you just gotten used to the filth?

If you are in the bowl, how do you imagine getting out of the bowl, emptying the water, cleaning the glass, refilling the bowl, and getting back into a healthy environment?

I would say, if you are that goldfish, either you learn to clean your own bowl, hire someone to do it for you, or you find yourself a new bowl.  There will certainly be some who will choose to swim in their own filth, until it chokes every bit of life out of them.  I see too many analogous goldfish swimming in filth, because they lack the skills necessary to maintain their own bowl, because they believe that someone will someday come and change the water, or they think they can just live with it.

If your fishbowl becomes filthy, what would you do?

HT: Leading Agile

Measuring (Project) Health

You'd think I would follow my own advice when it comes to my own health.  When dealing with project deliverables or tasks, I like to get feedback from the team as often as I can.  Ideally, I recommend daily feedback.  Realistically, there are extended team members who you don't deal with on a daily basis.  Due to their expertise, you may need to share this person with others on the program.  Notice I didn't call him or her a "resource".  Anyway, you need to make sure you do a few things, when interacting with these team members.  One, identify the maximum amount of time that will elapse between interactions.  Two, identify some threshold criteria.  Exceed the threshold and you should be interacting with this team member. Now, I've followed this prescription in the past, when dealing with experts like Software Architects.  Seriously, it doesn't matter the title of the person we're talking about.  What's important is you know you have maybe one or two of these types on your program.  The other important thing to note is if you don't do either of these things, you run the risk of this coming back and biting you.

3 indicators you've gone too far

1. You have not interacted with your expert within the predefined timeframe
2. You have not interacted with your expert after a threashold has been exceeded
3. Your expert has prescribed Levofloxacin to you

The Agile Introduction

When you meet someone new and they ask you what you do, what do you say to them?  Do you have a prepared introduction?  Have you prepared an explanation of your unique qualities?  If you think that is hard enough to communicate to the layman, try explaining Agile. If someone says "Hi, I'm Bob. I'm a Project Manager", most people get it.  We've all had a generation to get it.  Oh ya, so you manager some one or some thing.  I get it.  Now, when explaining Agile and how it relates to what we do, there is an extra layer of complexity.

For those in the Agile community, you'd be willing to take 10 minutes trying to explain Agile, rather than to be associated with the status quo.

But here is our problem as Agile proponents.  We don't all agree as to what Agile means.  There's a bit of a disconnect there.  I've heard people basically recite the Agile Manifesto when asked what Agile was.  The Manifesto (for Agile Software Development) hasn't been around long, being written and signed in February of 2001.  Though the authors signed it, I doubt they would all agree specifically what Agile is.

I've heard people describe Agile as "caring, loving, respectful"...  Though I don't discount you may see people exhibit this behavior, I don't go that far.  I'm talking Agile here, not my wife!  You see, to some, Agile is a living breathing thing.  But, I'm much more pragmatic.  I'm still passionate about Agile.  But, I'm not going to hold some dudes hand and sing Kumbayah by a campfire.

Let's get back on point.  The Agile Manifesto originally related to software development.  Some are now applying the 12 principles of the Manifesto and items the authors came to value to areas beyond software development.  This does not make these approaches any less "Agile".

I read a very interesting comment on the Agile Scout website, where someone explained how they use Agile as a Marathon Training Approach. One of the comments was: I think we are getting a little carried away here with Agile. Some say it is a philosophy (for developing software), but people seem to want to extend it to be a religion almost. I am sure that is not what the writers of the Agile Manifesto had in mind. This is a good way to get a good idea written off as a cult.

My response to this is an analogy.  For those who celebrate Christmas or think they know what Christmas is, ask them "What is Christmas?"  I am sure that is not what the creators of Christmas had in mind.

To summarize, Agile has become something bigger than what anyone could have imagined.  The concepts, approaches, and philosophies associated with it will continue to expand to other verticals as long as the Agile community (as a whole) accepts them.  So, how do I try to explain Agile to someone I just met?  Though I reserve the right to refine my introduction, I believe

I am a Agile Proponent

Agile focuses on the frequent delivery of something that works, by using small collaborative groups of people and small units of time to make sure whatever has the highest value get done first.  As each unit of time progresses, more gets done and more information becomes available to which future work can be done.

Like the image? Find it at Pictofigo

The Cave of Zombies

The “Allegory of the Cave” by Plato represents an extended metaphor that is to contrast the way in which we perceive and believe is reality. Plato said what we see are actually imperfect “reflections” of the ultimate Forms, which represent reality and truth.  In his story, there is a cave in which prisoners are chained down and forced to look at the front wall of the cave.  Behind the prisoners is a fire and puppeteers, casting shadows on the wall in which the prisoners perceive as reality.  Being you and I know there are puppeteers, we know the shadows the prisoners are seeing are not reality.  But, it's their reality, none the less. Once a prisoner is released, he is forced to look at the fire and objects that once provided his perception of reality.  Only then does he realize these new images in front of him are now the accepted forms of reality. Plato described the vision of the real truth to be “aching” to the eyes of the prisoners. He added they would naturally want to go back to the cave and look at what they had always seen as a pleasant and painless acceptance of truth.

Once a prisoner climbs out of the cave and is fully immersed in the rays of the sun, the prisoner would suffer bewilderment, fear, and blindness to the objects he was now being told were real. The natural reaction of the prisoner would be to recognize shadows and reflections. After his eyes adjust to the sunlight, he begins to see things as they really are.

Plato's allegory made me think about zombies. Oh hell, what doesn't!?

We're not just prisoners in a cave, we're zombies.  Those who have left the cave come to visit once in a while.  They may complain that the food outside isn't as good.  But, they've taken the uncomfortable step of leaving the cave and merely want you to eat something other than brains.  If you are a zombie still in the cave, the other zombies are going to tell you to just eat more brains.

It doesn't matter what kind of zombie you are.  If someone offers to expand your reality with ideas foreign to your own, don't be so negative.  Don't just dismiss them. Don't eat more brains.

Like the image?  Find them at Pictofigo

Agile Traffic Analogy

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

Project Voldemort

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

Agile and American Football

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

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

12 principles we follow

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. 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?