Garbage In, Gorilla Out- Know "What" before "Do"

"What do you mean he said it's crap?!?" Jake's voice thundered. I'm pretty sure there was steam coming out of his ears . I could feel my own kettle on a rapid boil myself so Jack must have been at nuclear meltdown stage.  I turned and cast a sympathetic eye down the table. Poor, Bob, our hapless product manager looked like he'd just been served up as the main course at a great white shark feeding frenzy.

I'll give him credit though, Bob didn't cower in the face of our rampaging development manager. I mean after all, it wasn't his fault, he was just the messenger. Bob nodded his head gravely, "he did. He went on to say it was lifeless, had no vision, was poorly put together and had no business being on the store shelf."  Ouch… Fiat Armburger was the man. If he gave your product a pass, you could name your price with the channel. But if he panned you, might as well start selling the office furniture now.

Jake shook his head, a look of complete disbelief washing over him. I don't think I'd ever seen him look so defeated. "We executed perfectly. We even shipped three months early. Hell! We delivered everything you asked for in." His eyes turned back to Bob at the last words.

"I know, I know," said Bob. "What can I say, we missed the mark. We'll just have to try harder the next time."

I jumped to my feet. "Well now," I interjected, because if I didn't Jake was going to levitate across the room and kill Bob with his eyeballs alone. "We have a stack of bug reports here. Bad review or not, we've got to fix these issues before GA. After all, we still have to ship, the schedule is committed."

It worked, everyone calmed down and we got back to making the product ready to ship. I don't know about anyone else, but all I could really do is wonder whether anyone would even buy it.

"Nope, it'll be the worst launch since Ishtar."

Great, just what I needed. A failing product and now a gorilla who thinks he's a movie buff. Why me?

"Well cause it's your fault." Hogarth offered up.

I spun my chair to face my personal gorilla. He was lounging on the wall contemplating his naval (yes gorillas have belly buttons, Hogarth's was large enough to misplace loose change in). "How on earth is it my fault?"

Hogarth looked up, producing a quarter from his naval. "Well technically it's Bob's fault, but come on doesn't it get boring always blaming  the product manager?"

"Hogarth, explain to me how this is my Bob's fault much less mine?" Though the idea of it being Bob's fault was certainly more appealing to me.

Hogarth smiled, "G.I.G.O." 

"I… what… " I stammered. Then my mind realized what he meant. "Oh… my george…"

Garbage In, Garbage Out:

GIGO is a term that reaches back to the dawn of the commercial computer age. It's a fundamentally simple fact that states  "computers  will unquestioningly process the most nonsensical of input data ("garbage in") and produce nonsensical output ("garbage out")." The overall concept goes back even father to early "computer" inventor Charles Babbage (now seeing a resurgence in fame thanks to the Steam Punk phenomenon) .

It's hard to argue with the concept, in fact the software programmers I know wouldn't even try. To them it's like trying to say "Brick+Music=42". It just doesn't work. You have to use good inputs if you ever want to have good outputs.

So then, why the heck do we think the magic solution is in the development soup?

For the sake of this discussion, we're going to take a scrum team. This problem applies to any kind of development process, from BDUF to XP. I'm using scrum because let's face it, some of us have held it up as the golden ticket to solve all ills. So let's see what happens when the golden ticket uses lead to develop.

The official Scrum Guide is seventeen pages long. Of those seventeen pages, about one page is devoted to the concept of a Product Backlog. This page covers that the product backlog is the Product Owner's responsibility, that it is important, that higher stories have more details, that it should be rank ordered and that it should be regularly groomed.

You can groom a Canadian Hairless cat all you want, he's still not going to win any beauty contests. A scrum team needs a good product backlog (requirements) to work from. If they don't have a good backlog, then  they can ship the project on time, on budget and it will still fail because it was a bad idea to start with. New Coke failed because there wasn't a need for it, everyone was happy with the old coke.

GIGO- If you don't take the time to figure out what you want, then you won't get it.

But, but that's not agile! You're saying I have to do big planning up front! See I knew agile was a crock.

Yeah, no…

You don't have to document the Library of Congress, before you start a project, but you need to make sure you at least understand what the customer wants and have an end vision in mind. You then have to make sure that when the developers are getting ready to start coding, they understand EXACTLY what is wanted for that functionality. You can absolutely be agile in your product planning process. In fact, you can just be agile in planning and I think you'll get a better project, even if development still builds in "waterfall."

The Gorilla Planning Outline:

I found much of my inspiration in Jim Highsmith's Agile Project Management: Creating Innovative Products. I heartily recommend the book for anyone involved in project planning or project management. Another good bit of inspiration came from Agile Learning Labs, a really great agile coaching and training shop in the San Francisco Bay Area. If I have stood farther, it is because I have stood on the shoulders of giants (Isaac Newton).

Note: This is an outline only. Within each stage I promote agile based exercises to get to the end goal.

The Cast:

Product Manager/Owner

Product Sponsor

Customer Voice/Representative

Architect*- Optional

Agile Coach/ Facilitator

*- An architect level technical person can provide valuable insight to this stage of the project. It is vital though to ensure this person(s) can separate business from technical constraints. An architect who is constantly focused on the how and how long will not add value to the process during this stage. The exception is in Stage 6, Estimate the Cost.

Stage 1: Defining the Product

Purpose: Create the “product box.”

Time Needed: Half Day

Description: Ensuring everyone thinks that blue is really blue is a fundamental starting point. If the product owner things you are building a Ford Pickup and the Sponsor is envisioning a Land Rover, you have a disconnect. This stage of product planning focuses on the overall corporate goals and customer “box” experience. The “box” experience is the level of experience you get when you pick a product up off the shelf and look it over. What compels the customer to buy? The core of these concepts comes from Jim Highsmiths’ chapter on Envisioning from Agile Project Management.

Stage 2: Layout the Product Story Outline

Goal: Create a timeline of the product's use and identify missing gaps.

Time Needed: Half day to full day.

Description: “How did we forget that feature?” has been a long asked question, typically so far into the development process as to require derailing the project to get the feature in. Story Mapping is a process that discovers the users, the end to end experience and then allows you to drive into the highest level of user stories but doing vertical break downs.

Stage 3: Create the Chapters (User Stories)

Goal: To create clear and concise descriptions of user experience with the product.

Time Needed: One week offline work, after Stage 2 and then half day.

Description: A poorly written user story can lead to the implementation of something that is technically perfect and a complete failure as it doesn’t meet the needs of the user, as envisioned by the product owner. A critical component of this stage is that even the highest level stories need a basic acceptance test to validate against.

Stage 4: Decompose the User Stories

Goal: Break large user stories down into iteration obtainable goals.

Time Needed: Half day (can be done with Stage 3 to save some time overall)

Description: One of the largest challenges in the creation of a backlog is to go just far enough with the details of a user’s experience and not to far that you’re creating a functional feature spec. Product Managers often struggle to not provide so much data that they are directing the engineers to a specific implementation – which can both stifle a creative new idea and can upset the engineers who feel they are being dictated to. Engineers who get too vague a story are faced with many challenges, not the least being “what exactly are we building,” “If I’d know that originally, I would have estimated this as a much bigger story,” and “This will take at least six weeks, I can’t do it in a four week sprint.”

By breaking user stories down to iteration manageable levels the team is able to better estimate value and cost (time to complete), removes confusions that can result in a feature that doesn’t match the vision of the product owner, allows for shorter iterations – which itself improves the overall development process by allowing more chances to apply the “inspect and adapt” philosophy of agile.

Stage 5: Value the User Stories

Goal: To create a relative ranking of all user stories on a project.

Time Needed: One to two hours

Description: P0, P1, P2 ultimately breaks down. Fifteen years ago I never even heard of P0 and you might actually see a P3 in a product. Today you see projects where everything is a P0 and engineering says it will take two years.

Doing force ranking, feature weighting and other traditional techniques rarely leads to the level of consensus required to create a final ranked list. The realistic question to ask teams, at this stage, is how often estimating against real world artifacts has worked. When was the last time a product forecast was accurate? Using agile values opens up the process to creating a system that creates agreement not conflict.

NOTE: This is one of the secret sauces of this process. In my next blog I document an excellent exercise for how to define business value for an entire release in just a couple of hours.

Stage 6: Estimate the Effort (Cost)

Goal: Rank the user stories in relative order of effort (cost to produce).

Time Needed: One to two hours

Description: Classic estimating of user stories. It needs to be done on even the grossest level stories for the product owner to be able to properly rank order the backlog. Otherwise a backlog can be skewed towards value, costs or even worse, gut judgment. Poker Planning and Delphi models have an inherent flaw of focusing on the story itself which leads to exact effort and not rank ordering estimates.

The Cast: This stage does not involve the product owner/stakeholder cast. Effort estimating is done by the engineers doing the actual work. It is important to not just have management at this stage but engineers doing the functional work.

Note: The developers should not have knowledge of the business value rating at this stage. They are just assessing the complexity of the future. If they know a particular feature is the absolute silver bullet, they may over or under estimate it.

Stage 7: Order the Requirements List

Goal: One backlog to rule them all.

Description: At this point the Product Owner has both a business value and a cost. These are both placed on the user stories. From here the product owner then uses their judgment and skill to create the product backlog. They weigh the value and cost of a story (feature) to create the backlog.

Note: In agile development, best practice is to groom the backlog once iteration with the product team. This is where cost can be reevaluated, better definitions of stories can be done and the product backlog reordered as a result.

The Transparent Gorilla: If you can see through me, you can see me.

 

In response to Agileexam Gate:

"Hey. Can I ask you about project Pompeii's status?"

I tensed up , turning slowly to face Molly. She was the program manager on another project, which had some dependencies on my project. Okay, had a lot of dependencies on my project. I plastered a smile on my face. "Sure, Molly, what's up?"

Looking down at her notes, she said "You're reporting green on the phase interlock grid?"

I nodded, "Absolutely, PIG is on track."

Molly scratched her head, "I'm confused, it's supposed to be fully complete in two weeks. We've yet to be able to deploy it without everything melting down. Is there a problem with it?"

"Problem?" Damn, my voice nearly squeaked. Fighting it back under control , I answered, " Look, it is nothing we can't resolve. We said it would be ready, it will be ready."

"I'm just concerned, we only have two weeks of slack, if PIG misses those dates, Prometheus is going to go down in flames," she said.

My smile slipped away. "You have an issues, take it to the PMO. I said it would be ready and you're questioning me? We're on the problem and we'll have it ready. Now excuse me, some of us have real work to do."

I spun about and stalked off to my office. The nerve she had! Of course PIG was risky. I mean how often to you integrate a phase oscillating projector into a self healing data grid? We just needed to focus and get the work done. It was on my and my teams shoulders to do. We didn't need to tell anyone about the process, we just needed to get it done. We all knew it would work, everyone else needed to just back off. I strode into my office and collapsed in my chair. I so needed a nap.

"Transparency… " Hogarth said from his corner of the office.

I didn't look at him, making every pretense of counting the holes in the acoustical ceiling tiles. I so didn't need a gorilla telling me about see through plastics.

Hogarth sighed, and heaved his bulk up. Lumbering over to my desk he leaned in to loom over me. "If you hold up a metal shield to me, all I see is myself. If you hold up a window, I see you. "

Ouch…

Make the insanity stop!

I rarely tackle current event issues. With twenty years of my own mistakes and witnessing a lot of strange things, I've got years worth of blogs . But I wouldn't be true to Hogarth and all I stand for, if I didn't stand up now.

Note: You have to read the Agile Scout's blog on his fact check of Agileexams.com for this to make sense. Also you may want to read Jesse Fewell's blog on the same subject.

Even in it's current form, Agile Scout's blog calls into question the business behind the product Agileexams. I don't think anyone I've talked to denies that the product is a good idea and it has value. What Peter Saddington (Scout) is calling into question is the business and marketing practices behind Agileexams.

Point and Counterpoint:

So, first off we have to ask the question, "Could Peter have done more research on his article?" or "Did Peter act too fast to get out his story?" The answer to this is a fully qualified "Maybe." I don't know everything Peter did to research the story. What I can say is that the person who's testimonial he highlighted had one hell of a name. Even having the full name of the person, it took me ten minutes to get the PMI certification registry to cough up his name (It's not a Google like search at all). I also know that I can't for the life of me figure out how to not show my certifications and that the default is for your certifications to be shown, you have to opt out. I do know that Peter reached out to me for my experience and reportedly he asked Agileexams' owner to answer questions, but was declined. So could he have done a better job in the first place? Possibly. But that's an answer you can probably give to 80% or more of all journalism done.

Now let's look at the response. Getting bad, questionable press is naturally something that no one wants. What you do about it though tells the world a lot about your character and causes people to form their own opinions. When Toyota had their gas pedal issues, they weren't raked over the coals for the problem. They were lambasted for how they responded to the problem. When Herman Cain was hit with the sexual misconduct scandal, people were shocked, but the real damage was in how he handled the accusations. No one was happy with the fact BP had their oil platform go boom, but people were furious with how BP responded to the disaster. 

Now let's urn it around . When the Twin Towers fell the rescue response was immediate and sustained. Resources poured in from all over the country and the response was incredible and public reaction was equally high. More recently, EMC's RSA division was hacked and that exposed hundreds of companies to security risks. EMC got in front of the issue, admitted the breach, worked with the affected customers and reissued millions of RSA tokens. In their next quarterly report, the RSA division reported great earnings. Their customers were so impressed, they bought more product, they didn't run away.

When faced with adversity, tackling it head on and with complete openness has proven to be the right way to go time and time again.

Following the Toyota way:

Unfortunately, Agileexams followed in the footsteps of Cain, Toyota and BP.

Before Peter had even published his article, before the content was known at all, Agileexams was threatening Peter with legal action.

After the article was published, Agileexams first responded by urging its customers to respond if they were harmed and to blog in defense of Agileexams. In this email, the company said it was considering legal action.

Then an email thread began, in which myself and several others who'd made comments on Peter's blog were treated to a front row seat between Agileexams and Peter. Errors in Peter's story were pointed out and Peter quickly made corrections to his article and apologized to both Agileexams and the individual originally cited in the testimonials section. That didn't end it. Agileexams demanded a full deletion of the article and a public apology. Using words like Unethical and "Not agile". In the same emails that were flat out demanding change.

Other questions have remained completely unanswered. More than just Peter have asked about what is the definition of "100 years of combined experience" or how "#1 PMI-ACP Exam Prep Resources" is justified. Is Agileexams just one person, or many?

Does it matter?:

Does it really matter if they have 100 years of combined experience, or if they can't substantiate being #1. If the company was just one guy, a stack of agile books and a website, would it change?

Yes and No:

No, it wouldn't change, if Agileexams was up front and open. Instead of spending time and money on a slick marketing campaign just focus on the product and make the product great. Quality is its own magnet of success. I personally recommended the site because of the sample tests, not because of any of the slick marketing.

Yes, it would change. If you fail to be transparent and open, customers lose trust. This is even more so in an agile community. Trust, Transparency, and Collaboration are all hallmarks of agile. You don't succeed in agile by reaching for a loaded lawyer as your first recourse.

The Gorilla's Stance:

I find myself in a difficult position. One I would much rather avoid than confront. The problem is, if I did avoid it I would be going against my own ethics, going against just what I was advocating in my blog on having a PMI-ACP credential. I am one of the first 515, I have a responsibility to the community. That doesn’t make it any easier.

I think Agileexams, as a product, is excellent. I had nothing but positive interactions during my time using the product. I think it is a good tool that doesn't slip to far down the Test Mill "were just here to get you to pass" rat hole. I had even approached Agileexams about writing some questions for them. Let me say this again. It's is a great product. I really hope it will succeed.

Which is why I'm so saddened by the perception that the business is not on the up and up. Perception- Hogarth and I really have to talk about this one in detail someday. The short form is, Perception is 9/10s of reality. You don't have to like it, you don't have to agree. The reality is perception matters. Just look at Bill Clinton. Did he, or didn't he? It doesn't matter, perception is he did and it will forever hang over his head. The Perception is Agileexams is not being open. The Perception is Agileexams will reach for legal solutions first and foremost. The Perception is Agileexams is hostile to inquiry. The Perception is Agileexams is not agile.

For me the straw was the closing line in the email thread I've been given front row seats to. The line was  in response to Peter's, both posting of the article and not issuing a public apology. Agileexams wrote- "What you did was not Agile."

Hello? Let's take a look at this.

Agile Value 1- Individuals and interactions over process and tools.

Agile Value 3- Customer collaboration over contract negotiation.

Agile teams don't reach for a baseball bat when they disagree with a customer. Agileexams threatened legal action before Peter ever posted his blog. Like it or not, Peter is as much their customer as the rest of the internet. Customers want to know what's going on. They often ask hard and embarrassing questions. Being agile means you respond open and truthfully, not with threats.

Agile Principle 6- The most efficient and effective method of conveying information to and within a development team is face-face:

Face to face is not possible be, but all of us know that email is the worst medium for communication. Pick up the phone and talk. Whether Agileexams intended to or not, they have been perceived as hiding behind an email address and first name only.

Agile Principle 2- Welcome changing requirements...

Peter reported what he knew. When he learned more, he amended the report. Then he amended it again. All based on one of his customers inputs (In this case Agileexams was his customer). But you don't throw out the entire project. If you make a mistake, you don't toss yourself off a cliff, you make it better.

So what does this mean to me? What does it mean to all of you?

Good question. This entire episode is being touted by some agilists who think the PMI-ACP was a bad idea in the first place. They are pointing to this as proof of credentials being evil . It also raises the "Test Mill" specter. Is Agileexams just in the business to get you to pass? Faithful Hogarists know how I feel about Test Mills and the ACP, so that one is doubly concerning to me.

I believe in agile and I believe in the value of a certification (done right).

Given that I can't in good conscience recommend Agileexams until it modifies its practices to be more transparent.

It's not about me, it's not about Agileexams, it's not about Agile Scout.

It's about AGILE.

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? mailto:jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

Power to the Gorilla! - Or, I passed the PMI-ACP now what?

"YES! I HAVE ARRIVED!"

Oh life was good, oh so good. I read the email one more time before leaning back in my seat with a self-satisfied grin. I even went so far as to kick off my shoes and toss my feet up on the desk. In a bygone decade I would have pulled a cigar from my pocket and lit it in a self-congratulatory act of hedonism. Instead I satisfied myself with lacing my hands behind my head and staring at the ceiling with a happy grin. Absolutely nothing could ruin my good mood, nothing!

My door opened, allowing a deep voice to fill the room. "Ding… Third floor, housewares, bedding, inflated egos…"

Okay, almost nothing. "Go away, Hogarth, I'm not letting you spoil my mood."

I could feel Hogarth lumbering into the room but I didn't turn my starry eyed gaze from the ceiling. I herd the snap of Hogarth breaking another branch off my poor fichus and didn't fret over it one bit. I'd just get another plant, it wasn't a big deal. Nothing could ruin my mood.

"Why would I want to spoil your mood?" Hogarth said. "I mean its not every day you earn a coveted inaugural slot in what's likely to become one of the industries influential certifications."

I kicked my feet off the desk and brought my gaze down to my fichus nibbling gorilla. "Really? You're not here to tell me about some monumentally stupid thing I've done? I haven't overlooked some gaping field of land mines, stepped on the toes of someone important?"

Hogarth shook his head, "nope, nothing like that."

I leaned back in my chair with a cheerful grin. "Yeah, it is pretty special to be on of the first hundred GOPHRs. I mean just getting into the Global Operation Project Handler Registered pilot program was an achievement. Passing the test was pure gold and now I have arrived!" I pumped my fists in the air to punctuate my last words.

Hogarth didn't say anything at first. He carefully finished pulling a long strip of bark free from the branch and sucked it in like a piece of spaghetti. Finally he looked up from his branch to look at me, my arms still raised ridiculously in the air. "Okay, you've arrived. Now what?"

"Huh? I've arrived. I did it. This is my ticket."

Hogarth nodded, "I see. But what are you going to do?"

"Do?" I stared at him perplexed.

He nodded again. "The price of greatness, is responsibility."

I threw up my hands again, this time in annoyance. "Hogarth! Don't spout Spider Man at me."

"Not Spider Man, Winston Churchill."

Having isn't Being

On January 10th I was informed that I had passed the PMI-ACP  certification exam and am now a certified PMI-ACP retroactively as of October 10, 2011, the day I took the test. Yes, I've been a PMI-ACP for three months and didn't know it. By the numbers I've heard reversed engineered, there are currently a little more than 500 PMI Agile Certified Practitioners (as of January, 2012). In comparison there were between 300,000 and 400,000 certified PMPs worldwide in 2011.

So what's it like to be one of the first? Well there was no balloon drop. Ed McMahon didn't show up on my doorstep with the Publisher's Clearing House check. In fact it doesn't really feel all that different. Now perhaps having three months pass from test to result lessens the anxiety, but I had none of the elation of seeing "You passed" on the screen when I received my PMP.

One thing did change though. Responsibility…

Now this is not a word I am unfamiliar with. Hogarth and I discussed the responsibility of project managers in a past blog. Still being one of the first to hold the PMI-ACP has caused me nearly as much reflection in a week as I have done in the many months on it since it was first announced.

I first blogged on the PMI-ACP with the "Potato, Pahtato Gorilla" in March 2010, where I talked about why I saw a value in the certification. While not directly discussing the PMI-ACP, when Hogarth played poker I stressed that a certification isn't the silver bullet it is just what shows people you should know what you are talking about. In my Lemming Blog I bemoaned how bad training could be a death knell for the certification. And finally, my last blog was a retrospective on my experience with the certification process. In addition, a good chunk of my blog this last year covered agile topics in large part because of my involvement with the certification process.

And through all these blogs there are some common themes that come back to responsibility.

And now that I have the certification, I know it's my responsibility to live up to both the certification and to Hogarth's maxims of speaking to the unspeakable. As one of the first 500 I have a certain responsibility to project management, agile and of course myself.

So with that, some specific thoughts being a PMI certified agile practitioner:

How do I fit in the overall agile community?

So how will we ACPs fit into the overall agile community?

Great question. Even more so than the PMP, it is no magic bullet. There are agilists that won't have anything to do with me just because I have an ACP. Agilists that think certifications are just proof you are part of all that is wrong with product development.

Then of course there are companies that know very little about agile and my having the ACP isn't going to be some spear and magic helmet. The reputation of PMI will lend it some credence, but at the end of the day what matters is my own work product.

For a large swath of the agile community I think what the ACP is going to do is to raise peoples expectations. If I'm a certified agilist then I better damn well know what I'm doing, right?

In the long run, it will be what certified ACPs do that will determine where we fit in. Which brings us to…

Representing the certification.

Going back to the Winston Churchill quote, there is a lot of responsibility that comes with being a trailblazer. If I'm the guy walking through the minefield, to find the safe path, then I darn well better not miss any mines. If I make it to the other side, but the team gets blown up, then I've failed. Because being and agile project manager isn't about me, it's about the team.

Being one of the first ACPs means I've have to be a lot. I've got to be an agile coach, agile mentor, agile evangelist and most importantly, I've got to be agile.

I guess it's a good thing I already felt I had to anyway. If I had to change to live up to the certification, then I shouldn't have been given it in the first place.

Wow, so all sweetness and light? Sounds like you drank the PMI Kool-Aid.

I don't think I have. If I did, someone slipped it into my coffee. No, I'm won't change who I am for this certification. I think the ACP fits who I am. It's not to say I don't have issues with it and that I won't raise my concerns.

The Name: PMI-ACP

I've not received my super dooper, official certification packet yet, and searching PMI's website is like trying to get a straight answer in a political debate, but as near as I can tell the official way to represent my certification is "PMI-ACP."

Really? Look, guys I've already got enough three letter acronyms behind my name to cause enough issues (PMP, CSM, CSPO, CSP). Giving me a seven letter one? Even the most storied professor of Oxford is going to just have three letters behind his name (PHD). Now I have to use a seven letter TLA? Heck, my TLAs are now longer than my entire name and that's no mean feet with my name.

There's only one other body out there giving out agile related certifications and those all start with CS, so I don't think anyone's going to be confused with plain old ACP. If you're worried that folks won't know where the certification came from, then do more marketing.

Seriously, I'll be referring to it as the ACP. I doubt anyone is going to mistake me as the "American College of Physicians"

Beware Prep Courses :

I've already referred to my Lemming Gorilla blog, but this bears talking (okay maybe it's a rant now) about. So let me climb up on my soap box for a minute.

Virtual doesn't cut it: I know, I know. It's a brand new certification and finding training isn't easy right now. The thing is, one of the key principles of agile is about the value of co-location. Yes, in a lot of real life use cases you'll be dealing with virtual teams, but when you are first learning agile you want to experience it first hand. You want to get into hands on exercises with fellow students. You need to focus when you're learning (We've all read email while watching WebEx training, admit it). Let me ask you this? Do you want your airline pilot to have learned by mail order? You need to learn agile hands on.

PMP Prep Course Shops:  You can't swing a dead tuna without hitting a PMI approved trainer for PMP prep courses. Some of them are very good, some of them are little more than test mills. And with all of them you need to look very closely before taking a ACP prep course from them. The PMP is a long standing certification with a unified body of knowledge. The PMP is also a certification for a multi decade profession. Most of us who study for the PMP already know project management really well. We spend more time learning the "PMIisms" than we do learning new. For the PMP, prep courses that are designed to help you pass the test make some amount of sense. I've still got a lot of issues with the ones that care only about getting you to pass the test, but that's a soap box for another day.

The ACP is new. The ACP is based on a very diverse body of knowledge (Ten years of structured agile, over sixty years of lean, something in between for many concepts we now call agile, and over ten books in the official PMI study guide. ) The concept of "Agile Project Management" is still relatively new, despite agile concepts being really old.

If you haven't been using agile, if you don't understand it and see the value, dare I say if you don't believe in it, then taking a three day prep course that gets you to pass the test is going to be the greatest disservice to you, to PMI and to agile as a whole. With the PMP, you need to learn the PMI way of thinking. With agile, you need to be agile.

So check out the credentials of any training shop you look into. Check their agile credentials. The one I talked about in my past blog had found a CSM willing to help them, but the company itself didn't have any agile background. If their sales pitch has anything to do with "It's the next big thing," or "Get on the bandwagon now," walk, don’t run from the place.

You can do it yourself: If you're an agile veteran, like the Agile Scout you probably don't need to even study. Compared to Peter I'm a rank amateur in agile with barely enough agile project hours to qualify for the exam. Yet I didn't take a prep course. I had a stack of books, Wikipedia, Google and Agileexams.com sample questions (Edit: Jan 20, 2012: At this time I cannont recommend the use of the Agileexams service) . I knew agile, I just needed to spend some time getting familiar with the common language that exists out there.

PMI is paying attention: One thing I really give PMI credit for, is being responsive to this. Rory McCorkle is the product owner for the PMI-ACP certification and product manager for the PMP certification. He's been very approachable since the beginning. So I took the issue of Test Mills to him. He told me that PMI is very focused on this and wants to ensure that the ACP doesn't turn into an test mill. He even encouraged me to report a test mill if I thought they were not being ethical about their practices. There's those ethics again.

Full Disclosure: I have talked with someone about building a prep course. If I did, I would build it on the principles of agile and it would be designed to codify agile, not get you to pass the test.

Conclusion:

So at the end of the day, does it mean to be a PMI certified agilist?

I don't have super hero cape, I didn't find the secret to untold wealth, It didn't change me into something else.

At the end of the day it’s a validation of who I am and what I've been doing since I added agile to my personal toolbox.

Joel Bancroft-Connors, ACP

The Gorilla Talker

Want me to talk to your gorilla? mailto:jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.