James Shore recently changed the entire focus of his company. This blog entry gives his reasons why. The blog post really struck a chord with me because I often use the phrase “To me mediocre is not acceptable.” Now I’ve found someone that agrees with me!  To me there is nothing worse than seeing a team not reaching their full potential because they are unable to see the problems they are causing themselves.  In fact, some teams even laugh about it when it is pointed out to them!  Grrr, don’t let that happen to you.  Read on for some things to watch out for.

There are many ways mediocrity can appear and seem harmless. If you are new to agile, here are a few that you need to be careful about.

• Daily stand-up meetings taking more than 15 minutes
• Team members being late to meetings
• “Just a little” testing not completed within the iteration
• Not inviting users, customers or stakeholders to iteration demos
• A retrospective where no action items for improvement are created
• Decreasing the committed scope of an iteration
• Team members not working on stories in priority order
• Boring daily stand-up, retrospective or planning meetings
• Defects regularly being found after an iteration is completed
• Iteration planning taking forever because the Product Owner is not ready
• Lack of release planning
• The big picture for the project is never made clear

There are many more things which could become commonplace and accepted.

DO NOT ALLOW IT TO HAPPEN!

Once you allow mediocrity (or worse!) to occur once, it suddenly becomes accepted behavior.  Do yourself and your team a favor and insist mediocrity is not acceptable!

Until next time I’ll be standing my ground on this issue while Making Agile a Reality™ for my clients.

Related posts:

1. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...
2. Agile antipattern: Doing Agile! I spent the past week in Orlando, Florida  at the Agile Development...
3. New to agile? Give thanks! Here in the United States we will be celebrating the Thanksgiving holiday...

Now that I have your attention, let me be VERY clear I don’t believe the title of this post.  However, many people do believe it, and that is troubling. 

Now that some of you are confused let’s back up a minute and explain the term PMP.  It stands for Project Management Professional.  It is a specific level of achievement obtained through the Project Management Institute (PMI).  The PMP level recognizes demonstrated knowledge and skill in leading and directing project teams and in delivering project results within the constraints of schedule, budget and resources based on the Project Management Body of Knowledge (PMBOK).  The PMP designation requires a significant amount of documented project management experience as well as demonstrating significant knowledge of the PMBOK through passing a rigorous test.  All of this is very good in theory, but there are some issues which may need to be addressed.

As I said in the first sentence, I don’t believe the title of this post as it is written.  Unfortunately, I can also see reasons why many people do have this particular belief.  The biggest reason being the way most PMPs look at the world of project management.  To them it is the traditional interpretation of the PMBOK or it isn’t worth doing.  I find this interesting because PMI has an official position which is the PMBOK is process independent.  It is simply good project management practices regardless of the underly process being used.  Yet traditional interpretations tend to conflict with agile interpretations of the same document.  I touched on some of this in an earlier blog post containing my feelings about agile and various bodies of knowledge.  At that time I was focusing on my observation that simply implementing a process based on a body of knowledge document was very likely to lead to a traditional waterfall process.  Now I want to take that thought a step further and say a traditional intepretation of the PMBOK while using an agile process is going to lead to conflict and eventually a project failure.  I know that’s a bold statement, but if you take a big picture view, a non-agile PM trying to help an agile team is definitely a square peg in a round hole.  Eventually something will break if the peg is going to get inserted at all.  Others agree with me.  Mike Cottmeyer has a presentation he does called Agile PMP: Teaching an Old Dog New Tricks.  Alex Hamer also has a blog post on this topic.

Fortunately, the PMBOK can be interpreted through something I’ll call “agile sunglasses.”  When you wear your agile sunglasses and look at the PMBOK you can see how the various practices may actually be useful in an agile world.  You may do them much differently than you would on a traditional project, but you can still do them.

I used to think it would be great if there was a translation between the PMBOK and agile.  I guess Michele Sliger and Stacia Broderick thought the same thing because their book, “The Software Project Managers Bridge to Agility” is exactly that!  It translates from PMBOK terms to agile terms and gives PMPs some direction on how to change from traditional PMs which are ineffective in an agile process to agile PMs with a lot of useful knowledge they can draw on to help their teams succeed.  This book is a must read for anyone stuck on traditional PM practices.  Anonymously drop a copy on your PMPs desk if you need to!  Click on the image of the book if you need to order it.  Go ahead, do it now, the rest of this post can wait.

In my experience the best agile project managers were also the best traditional waterfall project managers.  I believe the primary reason for this is they have found success by using some agile techniques without even knowing it.  This shows up when they are in a course and say things like “I already do that.”  When I press further I find out they have been very successful, and they are truly doing some agile things within their waterfall process.  At that point I can smile and know the team will be even more successful with the lighter weight agile process.

Now, back to the title of this post.  If it said “On an agile team never have a PMP who relies on a traditional interpretation of the PMBOK” I have to say I’d agree.  Unfortunately, the reality is many people fitting that description are in companies currently undergoing agile transformations, so what do you do?  I would start with some sort of coaching or mentoring.  Most people who have achieved the level of PMP are very knowledgeable and can adapt if given a chance and a path to follow.  In an organization undergoing agile transformation I like to schedule regular meeting time with all people fitting this profile.  This allows me to be sure they all share their experiences so they learn from each other and improve rapidly. At some point there is a moment when they spread their wings and fly again on their own.  Give them some time to allow it to occur.  However, don’t give them too much time.  There are some people in every role that won’t be able to transition to an agile process.  Project managers are no different in that regard from ornery developers that won’t change.

Until next time, get to work with your PMPs to help them adjust their habits and practices so that together you are working on Making Agile a Reality™ for your organization.  Let me know how it goes or if you have had experiences others can learn from.

Related posts:

1. Agile and various bodies of knowledge (PMBOK and BABOK) In case you aren’t aware, there are at least two international organizations...
2. Agile pondering: How does agile work with a team of 1? See that picture off to the left?  That is me and my...
3. New to agile? Remember how to say “No” No.  Only two letters.  Very simple word.  Yet for some reason, with...

I recently read this blog post from Chris Sterling and while funny, it made me wonder about the similarities between fishing and agile development.  Since I am a decent fly fisherman (I had an earlier blog post about a trip to Montana), I was definitely intrigued.  After some pondering I believe the two have significant similarities.  Starting with the fact trying hard doesn’t always lead to success!  Let’s dig deeper and see if there are further parallels in this analogy.

 Reasons for Failure

Maybe I’m stretching things a little bit, but it seems like the analogy holds up pretty well.

The point I’m trying to make is we need to pay attention to the details.  It is well known in fishing circles that small things can make a big difference.  The same is true in agile.  It may not seem like we are doing anything wrong when we don’t have continuous integration or automated testing, but those things add up.  This causes large scale failures over time.

Next time you go fishing, think in an agile way.  Don’t get me wrong, if your idea of a good day of fishing is sitting on the bank with a beer and watching a bobber, there is nothing wrong with that, but if you are in a place where it is really challenging to catch fish, pay attention to the details and adapt to what you see.

Now I want to go fishing, but until I get that opportunity I’ll be continuing to help organizations transform by Making Agile a Reality™.

Related posts:

1. Fishing in Montana is agile! I know you think the title of this post is absolutely crazy,...
2. Agile antipattern: Insanity! (5 insanity antipatterns) It is sometimes said the definition of insanity is doing the same...
3. Agile Architecture and Agile Testing – New Courses on the horizon Exciting news!  Some associates of mine are currently completing work on some...