AgileLIVE Webinar Series

Not seeing the productivity gains you expected?  Are you and your stakeholders losing confidence in your team's ability to deliver?  Are you sure you are measuring the right things? VersionOne and their Moving Agile into the Mainstream webinar series provides proven techniques to help you and your team with the tough issues facing agile managers, scrum masters and product owners.  Fifty-minute sessions feature case studies from teams that have succeeded in using agile methods to efficiently create better software.

Today, I saw "The Hybid PMO" by Sanjiv Augustine and Roland Cuellar of LitheSpeed

Even when agile methods succeed unequivocally at the team level, middle-management still faces two major, continuing challenges: managing a hybrid portfolio of agile and non-agile teams, and reporting progress upwards to the executive boardroom. How can PMOs bridge the gap between executive management weaned on plan-driven methods and predictability, and teams operating with agility in the face of uncertainty? How can they create a consistent reporting framework applicable to both agile and non-agile teams and communicate all-around progress effectively?

Sanjiv and Roland shared principles and techniques for the Hybrid PMO, and discussed some of the crucial management steps in establishing such a group, based upon their decade of experience in helping firms adopt agile at enterprise scale.

It doesn't matter if you want to learn from leading Agile pundits or just looking to get a few PMI PDUs.  This webinar was very enjoyable.  VersionOne will be uploading the webinar in a day or tow for those who were unable to join the live presentation.  All of this was FREE!

So, head on over to VersionOne and check out the other webinars from the series, from the likes of Dr. Alistair Cockburn, Bryan Stallings and Valerie Morris -  SolutionsIQ, and Michael Spayd - Collective Edge Consulting

The awesome Image and some of the content for this post courtesy of VersionOne

The Larger Goal

One of the things I find really interesting, when working within different organizations, is how everyone feels they are the true center of the universe.  If they are in Security, they see things one way.  If they are in Program Control, they see it another.  Regardless of the silo, plug in the functional area name and there will be different processes to follow.  They each have a different agenda that motivates them.  Even those considered as project/program overhead (Human Resources) will have their own way of doing things. Do I see something wrong with this scenario?

Do I think the organization could deliver more value if it were more goal driven and less process driven?

The answers? Yes and Yes

What's missing?  I think it's knowing where within the organization structure everyone is and how each can work together to reach the larger goals.

The larger the institution or project, commonly, the larger the bureaucracy that accompanies it.  We have our Executive bureaucracies, Director bureaucracies, and Manager bureaucracies.  Each step down the organizational chart, there is layer upon layer of bureaucracy.  Rather than the people at the top thinking more strategic and people toward the bottom thinking more tactical, there are just different shades of bureaucracy.  And you think that's bad, each (functional) branch of the organization has its own bureaucracy.

Commonly, people become too focused on their key subject matter in their functional area and forget the goals of the project or organization.   I see motivations shift to support the process itself instead of the product or service to be delivered.  When asked to do something that may directly apply to the highest goals of the organization, like "Deliver the product to the customer by this date", they act like their individual job is more important than getting the overall job done.  Instead of asking themselves what they can do to help the organization be successful, they may instead argue some point about how you didn't submit the request in the correct format, to the correct person, at the correct time.

But this post is not about being pessimistic about bureaucracies.  I'm not saying we don't need structure or processes.  This short story helps articulate what I'm trying to explain.

Perhaps you have heard the story of Christopher Wren, one of the greatest of English architects, who walked one day unrecognized among the men who were at work upon the building of St. Paul's cathedral in London which he had designed. "What are you doing?" he inquired of one of the workmen, and the man replied, "I am cutting a piece of stone." As he went on he put the same question to another man, and the man replied, "I am earning five shillings twopence a day." And to a third man he addressed the same inquiry and the man answered, "I am helping Sir Christopher Wren build a beautiful cathedral." That man had vision. He could see beyond the cutting of the stone, beyond the earning of his daily wage, to the creation of a work of art- the building of a great cathedral.

And in your organization or on your project, it is important for you to strive to attain a vision of the larger goal.

Like the images?  Find them at Pictofigo

---

What's in PMBOK 5?

Though I know people are hard at work, deciding what will go into the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) 5th edition, I can't help but add my 2 cents.

We're all armchair quarterbacks at one time or another so I'm rationalizing this post.

What is one of the biggest gaps in the current edition of the PMBOK, in my opinion?  It's the complete omission of (management) models or approaches.  Agile, Scrum, Kanban, Spiral, Waterfall, and RUP should be defined in the PMBOK.  It would be really nice if the PMBOK added an entire section dedicated to this, complete with diagrams and workflows.  I think there is a problem, if you find yourself sending people to Wikipedia to find a list of the different software development processes.  I completely understand there is more to the world of project management than just software development. But, I'm trying to make a point and provide an available resource for this post.

I've had people use the PMBOK as the excuse not to use Agile, saying it wan't explicitly listed.  I pointed out that neither was Waterfall.  I wrote a post titled "Agile is in the PMBOK so it must be true" to make a point.  If PMI wants the PMBOK to be used as the de facto standard for over 400,000 PMPs, they need to take a more iterative approach in releasing editions.

If anyone at PMI is listening, I would be more than happy to help.

Like the image?  Find it at Pictofigo

Failing The Exam

Here comes the rant

One of the things people know about me is I'm always willing to help them out.  I've been in the business of Project Management for 15 years.  I've lived the life as a Project Management Professional (PMP) and as a Certified Scrum Master (CSM).  These days, either certification will get you either praise or disdain. It just depends on the company you keep.  Some out there have heard me rant about people who I don't believe deserve to say they have a certification, based on their motivations.  You should get a CSM or a PMP as proof of a minimum level of competency; that you support what they represent.  I see them as mere indicators of where you are on the path of mastering your craft.  Some have also heard me rant about certification boot camps that will guarantee a certification or your money back.  Ask yourself, why do/did you want that certification?  My holier-than-though attitude kicks in when the response is/was "because it looks good on a resume".

Where am I going with this

I was approached a while back by someone looking for assistance in prepping for his PMP.  He is not a project manager (never was; never will be) and does not want to be.  But, his company told him to get the certification.  He got his membership with PMI, which his company paid for.  He then hit a wall when completing his exam application.  He didn't have the experience.  There are ways around that, right?  Just get someone to agree with your stories or pray like hell that you don't get audited (or both).  When he approached me, the first thing I asked was "what's your goal?"  His response was "to not get audited".  Um, ok.  Let's try this again.  "What's your long term goal?"  His response was " to get Corporate off my back."  I felt betrayed by PMI, the day I found out he registered for the exam and was not going to be audited.

The update

After attending a week-long (he needed the 35 hours of project management education) money-back-guaranteed PMP bootcamp last week, he sat for the exam.  He failed.  He failed badly.  Now, I'm not going to be mean.  I feel bad for the guy.  He now has to explain this to those who were paying him to take the exam.  I am relieved, however, that there is one less unquantified PMP out there.  But, when I asked him if he thought the exam was hard he gave me a very good answer.  He admitted he didn't even understand half of the terminology or formulas, let alone when and why he would use them.

And that is the broader lesson I want people to understand.

You need to understand when and why you do things.

Like the image?  Find it at Pictofigo

October Surprise

Nobody could have been more surprised about this October than me.  It was, by far, the best month this year.  It all started when my son kept asking me why.  Over and over again, why, why, why.  It lead me to write the why ask why blog post.  It made me ask myself if I was still on my "Critical Path". I think it's really easy for us to go day to day and forget why we do the things we do.  We sometimes forget our goals.

For the first time in a while, I thought about what was important to me and my professional goals.  I realized I wanted to get more involved in both the Agile community and the PMI community.  I realized I wanted to do more to educate, advise, and support.  Most of all, I wanted to deliver value.  You may hear me rant from time to time about the ecosystem surrounding the PMP certification.  As PMI rapidly approached 400,000 PMPs, I remember back to the days when I was passionately living Agile and Scrum every day, not just overseeing a program using a heavy waterfall approach.  But we all need to pay the bills.  I've done what I can to leverage Agile methods where I can when I can.

It was time for a reality check.  I signed up to attend the PMI North American Congress in Washington DC.  A few days before it started, I met up with 4 Agile pundits, all in Washington DC, attending the PMI Leadership Institute Meeting (LIM) and representing the PMI Agile Community of Practice (CoP).  After having a few drinks and exchanging ideas, it was the most inspired I had felt in over two years.

The next week, I attended the Congress and saw two very conflicted worlds.  I saw a very strong push by PMI to support Agile.  Everywhere I turned, there were banners or messages supporting the PMI Agile Community of Practice (CoP).  I then spent 3 days attending Agile centric sessions, all of which were introduced by Frank Schettini, Vice President, Information Technology, at PMI.  The message?  Agile is here to stay.  PMI supports Agile.  PMI uses Agile.  How was any of this conflicted?  The average Congress attendee appeared curious but also very ignorant to what Agile was about.  I don’t find it surprising, considering there is a complete omission of the word “Agile” in PMI’s Project Management Body of Knowledge (PMBOK®) version 4.0.  But, the PMBOK version 5 is in the works.  A new PMP credential exam is being release in August 2011.  There is hope for them yet.  I met many Agile thought leaders over the course of 3 days.  At the end of those 3 days, I knew I was back on the Critical Path.

Later in the month, on October 22nd, I attended Agile Tour DC.  I was able to immerse myself in Agile for an entire day.  This time, it wasn't just the speakers who knew and supported Agile.  Every person I spoke to was curious, excited, and optimistic about the future.

I then published an announcement that The Critical Path had been nominated for the  Computer Weekly IT Blog Awards 2010 in the area of Project Management.  You can vote for me if you like.

On October 24, I found a quote by Steve Jobs that spoke to me and left me feeling inspired.  About the same time, Mike Cottmeyer of Leading Agile recommended I read Dan Pink’s book, Drive: The Surprising Truth About What Motivates Us.  The book had a major impact on the writing for the rest of the month.

Along the way, I wrote a few posts in my Zombie Project Management series.

On the 27th of October, Agile Scout published my contribution to their series "the State of Agile" and I focused my editorial on Mastery-based Learning and the Paradox of the Certification.

The month was concluded by my reporting that PMI had reached 400,000 PMPs.  Again, I wanted to touch on mastery-based learning and the paradox of the certification.

And so concludes October 2010.  One of my core professional goals is to promote Agile methods and principles.  Another is to educate and inform the collective project management community on sound methods and approaches.  All of this under the umbrella of mastery-based learning.

I will continue to be optimistic.  The best is yet to come. Keep your eyes out for the article I'm writing for PM Network magazine. Stay tuned for announcements I will be making in November.

Like the image?  Find it at Pictofigo

---

Disclaimer: The link to the book is an affiliate link. If you buy a copy, I could make $1

---

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?

State of Agile

I was recently asked by Agile Scout to write an article for the State of Agile series. My article, entitled Mastery-based learning and the paradox of the certification was published on the AgileScout blog this morning.

Regardless, if you agree with me or not, your comments are welcomed.

http://agilescout.com/the-state-of-agile-derek-huether/

Waterfall Zombie vs. Agile Zombie

Back on October 12 (2010), I had the privilege of seeing Michele Sliger do a presentation titled "Hello Agile, Goodbye Scope Creep".  In it, she presented a compelling argument as to why a Waterfall process used to work so well for projects and why Agile is becoming more and more prevalent and successful.  You know me by now.  I can't help but draw a parallel between Waterfall versus Agile and old-school-dragging-their-legs zombies and new-school-all-out-sprinting zombies.

waterfall_zombie

agile_zombie

Waterfall Zombies

Back in the day of Night of the Living Dead, Day of the Dead, and even Dawn of the Dead, zombies were sooooo slooooow.  You usually had enough time to time to go to the gun shop and pick up a few cases of ammo, pluck them off one by one, all before they would change course and lumber after you.

Those were the days, when you could actually plan your attack on the zombie populous and carry it out.

Yes, when Waterfall was big, zombies were slow.  You actually had a fighting chance to outrun them.  That is, until you made some foolish mistake like not rolling up a car window or fumbling with your car keys.  Come on, people!

Agile Zombies

Now, zombies are fast, fast, damn they are so fast!  These aren't zombies like I remember them. These "28 days later" style zombies look you square in the eye and they are sprinting after you.  They are quick to react.

Now, I'm just looking for an excuse to put zombies in a post.  But, truthfully, something has changed.  Why is it, more and more projects are leveraging Agile methods and not using Waterfall?  Is it ADD?  It is just a bright shiny toy?  No, it's evolution.  Things change over time.  The one constant that seems to be happening is communications is a lot faster than they used to be.  The famous "Midnight Ride" of Paul Revere of 1775, where he road horseback across the countryside would now merely be a 21 character Twitter Tweet British coming! #fail

But, I would be doing you all a disservice if I didn't let you read what inspired me to write this post.

From Michele Sliger's original post title Hello Agile. Goodbye, Scope Creep!

Fifty years ago, planning out the scope of an entire project and locking it in worked because the pace of change was much slower. Teams had time to analyze, design, code, test, and deploy the product before their customer could change their mind. It was in the late 1980s that all of the inventions that speed thoughts of change started being used by the general marketplace: the personal computer (PC), Internet, email, and cell phones. The speed of communication increased, which increased the speed of knowledge, which drove the speed of change. Teams using the traditional plan-driven approach to product development could not keep pace with this new speed of change...

...A new approach to product delivery was required in order to take advantage of the technological advances and speed value to market. And it had to abolish the philosophy that change was bad, and instead embrace it. It had to give teams the flexibility they needed to react to change, and the framework and discipline to execute change.

Like the images?  Find them at Pictofigo