Official PMI-ACP Numbers

The PMI-ACP pilot has concluded and the Agile Certified Practitioner certification is officially one month old.  The numbers are in!  Per PMI Today, January 2012 concluded with 542 PMI-ACPs.  Not too shabby for its first month.  The PMP is still PMI's shining star, at 4047 new PMPs.  What surprised me were the numbers of PMI's other certifications.  Only 11 people got the PMI-SP in January.  It makes me wonder, what is the PMI-SP certification's value and longevity in the PMI ecosystem?  I ask because the PMI-ACP reached a number in one month that took the other certification a few years. And so it begins.  Will PMI-ACP be the next PMP?  What do you think?

Waste In Software Projects

This evening I attending the monthly Agile Leadership Network event. I noticed a very familiar slide on Waste In Software Projects. It looks familiar because I have it in my training deck as well! Yes, my Introduction to Agile class has a slide that credits the Standish Group Study reported at XP2002 by Jim Johnson, Chairman.  In reviewing software systems, Jim Johnston, Chairman of the Standish Group, determined that in systems defined and delivered using a traditional / waterfall style approach almost half of all features developed and paid for are never used.  The question this evening was, for the 45% of the features that were never used, what was the cost incurred?  Well, I can tell you it's probably a lot more than 45% of the budget!  What if the features that were never used were actually the most costly as well? The rule we should learn here is we should eliminate the waste at the source, before it makes it all the way to the Production environment.  If a feature or product is never used, it's waste. But, since XP2002, have we learned our lessons?     Are we still delivering features that customers will never use?  I figured I would create a quick Google Doc that would collect some data. After giving it some thought, I decided to remove the link to the Google Doc.  The collection of data was just a distraction from the actual blog post.  Thank you to those to participated.

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

Say Goodbye to that Expensive Meeting

Back in August (2010) I wrote about attending a $17,904 meeting.  It was painful to watch the PMO have a 3 hour meeting every month that seemed to cost so much but deliver so little value.  As a follow-up post, I wrote about the value proposition for the expensive meeting. I am happy to report that the meeting in question has been cancelled indefinitely.  In one year alone, the cost savings is $214,848.  Wouldn't you like to have that kind of money added to your budget?  I want to be clear that I'm not being a hater of meetings.  I'm being a hater of waste.  Time and money are precious and I strongly believe we need everyone to communicate more.  But it's about communicating effectively.  I can facilitate the communication of more strategic information, without saying a word, by using a enterprise level Kanban.  I can facilitate the communication of more tactical information, by having Daily Scrums or Stand-ups.

Though the cancellation was months in the making, I commend those who finally made the difficult (but necessary) choice.  It's easy to complain about things but accept the status quo.  It's hard to ask why and then act on it appropriately.

Drawings by Pictofigo

Team-Based or Value-Based

I'm currently reading a book about Systems Analysis and Design.  In a chapter discussing Agile Methods, one of the statements really rubbed me the wrong way.

The Agile Manifesto is a set of team-based principles...

For the last 6 or so years, I've assumed the Manifesto was a set of "value-based" principles.  That is, at its core, Agile is about delivering value or eliminating waste.  What I like about the Manifesto is it leaves a lot to interpretation.  It doesn't spell thing out to the N^th degree.  But, I'm very curious what the community thinks.  How would you describe the principles?

Please leave a comment.  Tell me what you think.

---

Mura Muri Muda

I had the wonderful opportunity to meet and listen to Jeff Sutherland a few days ago. For those who do not know who Jeff is, he and Ken Schwaber created Scrum.  It was really quite amazing to listen to him speak.  The topic of the talk was Using Scrum to avoid bad CMMI implementations.

Scrum and CMMI are often at odds with each other. What does each approach bring to the table? Scrum promotes the idea of focusing on the most important product issues first and supports frequent communication. CMMI brings a structure that promotes consistency and discipline to avoid waste and rework. So, why should we try to combine both approaches? Is this combination a good idea?

This post isn't going to go into detail about the entire talk. Rather, there were three words Jeff said that had me scrambling for my pen. "Muri, Mura, Muda".

The Toyota Production System identifies three types of waste (Muri, Mura, Muda).

Muri (無理, “unreasonable”) is a Japanese term for overburden, unreasonableness or absurdity.

Mura (斑 or ムラ) is traditional general Japanese term for unevenness, inconsistency in physical matter or human spiritual condition.  Waste reduction is an effective way to increase profitability.

Muda (無駄) is a traditional Japanese term for an activity that is wasteful and doesn't add value or is unproductive.

With commercial organizations, I consistently see two primary goals:  [1] Make Money and [2] Save Money

But as you drill down into an organization, these two goals are not as obvious.  So, to address this, I rewrite the two goals as:  [1] Deliver Value and [2] Eliminate Waste

When we reach this point, muri, mura, muda come into play.  In your day-to-day activities, are there areas you can make more efficient or improve?  Do you really need to go to that meeting or can someone just email you an agenda before and minutes after?  In your project lifecycle, do you really need a 10-step process workflow or can you achieve the same goal with just 5 steps?

Here is a practical exercise:  Make a list of activities you have to do this week.  Ask yourself why you need to do each of those activities. Do they map back to the core mission of your company?  Should any of these activities be postponed until the goal is clarified?  Should you just NOT do one of them?

I have a daily meeting at 10:00.  Why?  I fill find out what the team did yesterday, what they are doing today, and what impediments they have.  My job is to help facilitate their activities and remove roadblocks.  This 15 minute meeting is a keeper.

I have an invite to the Finance Working Group meeting on Monday. Why? Hmmm.  That's a good questions!  The meeting is scheduled for 1hr.  I know that it traditionally lasts 2-3hrs.  No invoice was attached in the meeting invite.  That leads me to believe they are going to review 500 pages as a group.  Though it's necessary to review the invoice, this is a very inefficient way of doing it.  I will send a request for a copy of the invoice to review when I can.  I will decline the meeting invite.

Of those activities on your list, highlight which ones just don't sit well with you.  Really listen to your gut. Are any items on your list an activity that does not directly translate into providing value?  Are any items on your list going to somehow cut into your personal life?  Are any items on your list literally a waste of time, money, or energy!?  If you can scratch any one of these items off your list, you are on the road to Kaizen (改善) (English: Continuous Improvement).

Before you accept that next task or meeting invite, ask yourself if there is a better way.

HT: Wikipedia

Like the drawing?  You can download it free at Pictofigo

Conflict in Value Perception

This weekend I witnessed a true conflict in value perception.  We're not talking values like: - We treat others with respect - We are humble

Rather, it's about what the Customer (Product Owner), the Vendor (Core Team), and the I (Facilitator) believe has value.  I see direct value, like actual delivery of product, and indirect value, like mitigating risk by facilitating communications.

We started a deployment cycle that is going to take some time.  The team activities are clearly defined and level-of-effort have been estimated.  Dates in which potential risks could arise have been identified.  This is all good.  Until an activity begins, we won't be certain if a risk will be fully realized.  This is why I'm a really big proponent of daily communications.  Every morning, we have a 15 minute (status) meeting.  (The culture demands that we call it a status meeting so I'm good with it.)  The extended team is distributed (3 locations) so this is a little challenging.

Though I stressed to everyone the importance of daily communications (at a minimum), this weekend I was a little shocked at what happened.  Deployment activities were taking place over the weekend.  There was a trigger point for a risk that had been identified.  During the Friday status meeting, the Customer informed the team that they would not be on the status call.  Though I had agreed to be on the status call, this was a bit of a paradox.  I am a facilitator.  Per the contract, I can not act on behalf of the customer.  IF the team ran into a roadblock over the weekend, the customer would not know until Monday morning.  We could potentially be delayed by two days until the customer could provide feedback and direction.

So, what happened over the weekend?  The team did indeed run into a roadblock.  But, they were empowered enough to get the work done.  Because risks had been previously identified, a mitigation strategy was in place.  The team was able to bring in team members, over the weekend, without having to consult with the customer.

I still believe if the deployment is going to be a success, all parties must be fully committed.  We're all in this together.  I'll never ask a member of my team to do something that I wouldn't be prepared to do myself.

Something David Bland said at the APLN DC meeting really resonated with me this weekend.  He said,

When dealing with distributed teams, keep the feedback loops tight.

David could not have been more right. We dodged a bullet this time around. Empowering the team allowed us to do this. But, the customer took an unnecessary risk, by intentionally lengthening the feedback loop from 24 to 72 hours.

Like the image? Find it at Pictofigo