I attended a PMI session this week called “Why PMI-ACP Certification is Red Hot…and How You Already Qualify to Receive It.”
It’s rare that I attend user group meetings in my home town, as I have been traveling for projects for most of the past 7 years, but this subject was right up my alley. I was eager to hear how the PMI is addressing agile (after practically ignoring it for most of the past 10 years of its existence).
I have a problem with the title of the talk, for one thing. Though the speaker lamented the “pass/pass” nature of Certified Scrum Master (CSM) certification offered by the Scrum Alliance, the title of this talk indicates that you, dear PMI member, are already qualified (without any experience or understanding ?) to receive (not just sit for the exam, but receive) ACP certification.
Second – I don’t think it’s “red hot”. I did a quick search on DICE (without geographical restriction) for ACP and got 14 hits. A search for CSM got 86. I was [pleasantly] surprised at how few hits I got on both. “Scrum” turned up 2,811 hits and “agile” turned up 8,765. I admit that some uses of the word “agile” are probably Webster’s definition, but I doubt scrum postings refer to rubgy.
The slide deck from the presentation I attended includes a visual of a “Crossing the Chasm” example (from Geoffrey Moore’s 2002 book of the same title) showing that, though Scrum Alliance (not Agile Alliance or any other org mind you) were useful for Enthusiasts and Visionaries in the beginning, PMI is “better positioned” to “cross the chasm” with Pragmatics, Conservatives, and Skeptics. He may be right; they have 500,000 members and a 40-year track record. But the content I’ve seen from PMI on agile indicates that the understanding is not yet there. And I’m not sure their certification approach is well-equipped to deal with an empirical process. (For the record, I attended a 10-week PMP training session – before my agile exposure).
Some areas of misunderstanding I’ve seen from various sources:
Mapping a work-breakdown structure to agile feature decomposition as a simple matter of terminology misses the subtlety of vertical slices and defining progress through “working software”. A “story” is not just a WBS “activity” in different clothing.
Mapping “similar” roles from classic project management to agile by suggesting that a senior project manager is like a product owner and a junior PM is like the scrum master misses the whole customer involvement and product owner as a customer proxy concept.
Agile is sometimes depicted as having a primary focus of avoiding waste or providing productivity improvement. This focuses on efficiency and misses the more important (my opinion) matter of effectiveness. Getting the wrong product out without waste helps nobody. Effectiveness – “doing the right thing” is about listening to the customer and adjusting your preconceptions based on observation. Agile is not just about eliminating waste (e.g. useless documents). It’s more about getting to the right destination – even if more slowly. I know it’s harder to sell that way.
Showing a cone of uncertainty that is narrower at the beginning based on iteration length misses the point. I am not more certain at the outset just because of the iteration length I’ve chosen. I haven’t thought deeply about this yet, but it seems to me that the only impact of iteration length on the cone of uncertainty is the fluidity of the narrowing. That is – with 4-week iterations, you get a more marked narrowing every 4 weeks where with 1-week iterations, you get a more fluid narrowing – smaller narrowings, but more frequent.
Presenting SCRUM in its 2002 form (ala Beedle/Schwaber) with 30-day sprints is crazy. I’ve never seen anyone do 30-day sprints. Imagine scheduling a recurring meeting for, say, your sprint review, at “every 30 days”. It would be a different day of the week each iteration. 4-weeks, 3-weeks, 2-weeks, 1-week, and 1-day are the variations I’ve seen. I also can’t believe that people still show slides that depict 4-hour sprint planning meetings and 4-hour sprint reviews (regardless of iteration length). The problem here is that you cannot codify an empirical process. You can only provide guidance, rules-of-thumb, and context/environment for which to account. Here is where PMI faces its most significant hurdle I think.
I’m accused sometimes of answering questions with “it depends” more often the people would like. I once had a client who insisted that I should be able to tell him the optimum agile team size. People often ask for the optimum iteration length. There’s no one answer for these questions. They are all context sensitive. The good thing is that, in an empirical process, you try something, see how it works, and then adjust over time. (I’ll leave the incongruence of this empirical approach with antiquated “tell-me-up-front” budgetary approaches for another discussion).
I think classic training is ill-equipped to convey the complexity of empirical processes. Think back to your high school chemistry classes. Did you learn more from a book, or from the experiments? Game approaches (ala Innovation Games and GameStorming) are, I think, the only hope we have to teach empirical approaches like agile/lean (not just scrum) effectively.
It’s easy to critique from the outside. I’m sure the PMI-ACP folks have the best intentions. I’m undecided about whether it’s worth spending time to pitch in to help, or to write it off as yet another useless certification.
Next post – I took the ACP survey on the PMI site. My results and comments will follow. (I missed 3 out of 20 questions).