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

Those PMI PDUs

OK, so you got your certification or accreditation through the Project Management Institute (PMI).  Now you need to plan on getting 60 PDUs over the next 3 years.  Is this too much to ask?  I don't think so.  How would you feel if your doctor never learned anything new, upon graduating from medical school?  Stakeholders should feel that same about people managing or leading projects. Over the course of the last few years, I've witnessed quite a few people who don't actually work as project managers get their PMP.  I know, you've heard me rant about this before.  But, since these people were able to navigate the system, what can the system do?  Well, I see the PDU as a mechanism that can continually attempt to separate the wheat from the chaff.   For some who really aren't contributing to the profession, and were just looking for three initials for a resume, the added cost and effort might not be worth it.  To be fair, I also know people who are very experienced and knowledgeable in the area of project management.  Requiring them to seek out and log PDUs is just an added deterrent to getting the PMP.

Back on topic, I break down the people getting PDUs into 2 groups.  Those who earn their PDUs over the course of 3 years and those who buy theirs.   Since I watch at least 1 free project management related webinar every other week, I ask myself why anyone would ever pay for them.  But, I digress.  Upon hearing the PMI was introducing a new PDU category structure as of 1 March 2011, I figured I would take a look.  What was once 15 categories will now be 7.  Without going into grotesque detail, I'm going to give you the 50,000 foot review.  In plain English, I like it.

Not only did the PMI modernize the language to include blog, webinar, and podcast, but they also grouped the PDU categories into 2 divisions.

1. (Receiving) Education

2. Giving Back to the Profession

I particularly like the language of "giving back".  When I think of the PMI, being charitable or giving back isn't really one of the first things that comes to mind.  I see this category naming as a step in the right direction.  I noted my disappointment in the lack of giving back in October (2010), when I was comparing the AgileDC conference and the PMI North American Congress.

I only have 2 recommended changes, if PMI would consider making a modification to the PDU requirements of the future.  First, I would ask PMPs to get PDUs in all 5 process groups.  I think people tend to get PDUs in process group or knowledge areas they are already proficient.  Second, now that the PMI has identified giving back to the profession, perhaps in a few years they'll add giving back to the community?

Like the image?  Find it at Pictofigo

The Stormy Present

The dogmas of the quiet past, are inadequate to the stormy present. The occasion is piled high with difficulty, and we must rise -- with the occasion. As our case is new, so we must think anew, and act anew. We must disenthrall ourselves, and then we shall save our country. That passage was read by Abraham Lincoln in 1862.  As I read it today, I couldn't help but think of a parallel.  I hear of projects struggling and hear people complain that this is just how we've always done it...and that this is good enough.  Why don't you stop and ask yourself why?  At a time when the country and the world struggle financially, shouldn't you consider just for a moment, that the ways we used to do things may no longer be good enough?  I think if you let go of the past and keep an open mind, there is time to save your project.

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

Biohazard Anniversary

Rather than be in the office, on my 2nd anniversary of advising a FedGov PMO, I'm at home.  Last weekend we went to a holiday party and one of the party-goers (who looked pretty bad) said she was really sick.  Um ya, thanks for that little holiday gift! My wife fell victim to the bug a few days later.  Might I say, without going into details, that it wasn't pretty.  I was a little nervous because I figured I would be next.  Additionally, I work in a common workspace.  I didn't want to infect the team with this. Last night, the other shoe dropped.  Our 5-year-old son was bitten by this unholy bug.  Let's just say we're waiting for the cleaning crew to arrive. Oh, and the smell!  What the hell is with the smells that go along with this kind of sick?

Sorry I don't have a good post about lessons learned from the last year.  Perhaps next week.  Until then, please go wash your hands! Mitigate the risk of getting this.

Take the Oath

Over the last few years, I've seen more and more people get certifications (or accreditations) from PMI, Scrum Alliance, APMG, and now SAFe.  Some will demonize the organizations for offering certifications and accreditations without actually proposing anything to deal with what they perceive as a problem. I believe certifications and accreditations are only as good as the people who get them.  One component I see missing is an oath of honor.  Yes, like Kingon honor or knights of the round table honor. (oh ya, I'm a geek)

When I wanted to be a Boy Scout, I met the qualifications.  But I then took an oath.

When I wanted to be a U.S. Marine, I met the qualifications.  But I then took an oath.

When I wanted to be a Freemason, I met the qualifications. But I then took an oath (which I can't repeat)

Not to compare project managers and leaders to doctors, but they take the Hippocratic Oath!  From that, I took inspiration.  Instead of trying to save lives, we're trying to save projects.

So, here is my first shot at it.  I call it the Metis Oath.  Metis was the Titan goddess of good counsel, advise, planning, cunning, craftiness and wisdom. Let me know what you think.

Metis Oath

I swear to fulfill, to the best of my ability and judgment, this covenant:

I will respect the hard-won gains of those practitioners in whose steps I walk, and gladly share such knowledge as is mine with those who are to follow.

I will apply, for the benefit of the stakeholders, all measures [that] are required, avoiding those twin traps of overtreatment and therapeutic nihilism.

I will remember that there is art to project management and leadership as well as science, and that empathy and understanding may outweigh all other things.

I will not be ashamed to say "I know not," nor will I fail to call in my colleagues when the skills of another are needed for a project's recovery.

I will respect the privacy of my stakeholders, for their problems are not disclosed to me that the world may know. Most especially must I tread with care in matters of project success or failure. If it is given to me to save a project, all thanks. But it may also be within my power to fail a project; this awesome responsibility must be faced with great humbleness and awareness of my own frailty.

I will remember that I do not serve a budget, or a schedule, but a human being, whose success may affect the person's project and economic stability. My responsibility includes these related problems, if I am to care adequately for the project.

I will prevent waste whenever I can, for prevention is preferable to cure.

I will remember that I remain a member of society, with special obligations to all my fellow human beings, those sound of mind and body as well as the infirm.

If I do not violate this oath, may I enjoy life and art, respected while I live and remembered with affection thereafter. May I always act so as to preserve the finest traditions of my calling and may I long experience the joy of managing and leading those who seek my help.

Pomodora Relationship

I have a dirty little secret.  I have an on-again off-again love affair with the Pomodoro technique.  Though I deal with a wicked case of ADD, I seem to keep it in check, thanks in part to my Personal Kanban.  The other method I use, though I admit not as commonly, is a pomodoro timer.  When things get really bad, I break out the timer.  And ya know, things get back on track!  You'd think I would learn. If you find yourself reading this blog, you'll find that I'm a proponent of  using simple techniques to get things done.  If you're looking for me to do a deep dive on policy, process, and procedure, you're in the wrong place.

So, how do I get some of my work done?  [1] I limit my work in progress (WIP) and [2] I limit my time (timebox). When I do both, I tend to stay focused and deliver more. The pomodoro technique, like other techniques I like, is pretty darned simple.

So, let's talk about my Piggy Pomodoro!

1. Choose a task to be accomplished
2. Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3. Work on the task until the Pomodoro rings, annotate the task you were working on
4. Take a short break (I take 5 minutes)
5. Every 4 Pomodoros take a longer break (I take 10 minutes)

As part of this process, I'm moving tasks on my Kanban from Backlog to Work in Progress.  If I take a break, I move it to Blocked.  When I return, I move it back to Work in Progress.  This allows me to visualize what I'm working on and know what I was working on before my break.

Have a Kanban or Pomodoro story?  I would love to hear it.

Why do I use a Piggy, you ask?  Because tomatoes give me gas and Chickens would just be wrong.

Image:  Amazon

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