Certifiably Gorilla- A retrospective of the PMI-ACP

Tap, tap, tap… Click to refresh. Sigh, “nothing.” Tap, tap, tap… Click to refresh. Sigh, “nothing.”
“What’cha doing? ”
Groan, just what I need. “I’m waiting for an email, Hogarth.”
My banana breathed gorilla leaned on the desk, causing it to groan in protest. “You do realize that PMI said it wouldn’t be until January that they said who passed the ACP?”
I threw up my hands in annoyance, “Of course I know that! And it doesn’t make it any easier to wait.”
Hogarth mused thoughtfully while I clicked refresh again on my Gmail account.  “So why you’re waiting to find out the results, isn’t this when agile type folks do a retrospective?”
Sigh… I hate it when he’s right.
PMI ACP Test Retrospective:
I took the test on October 10th, 2011 as part of the initial test pilot. Before reflecting on my own personal experience, I think there is a value in looking at the overall results. Ah, yes, astute observers will note that there are not results. Originally we were all supposed to have been told of our results by the middle of December. Well not only did we not get our results by then, but it would be closer to late December before we got an email saying we wouldn’t get our results until January.
Now January in and of itself is not a big deal. I’m really not all that surprised. What I am surprised in is it wasn’t until the results were late that we test takers were told. In agile communication is paramount and if you are going to fail, own up early and often. Still, even the best make stumbles along the way.
Now one thing that the PMI Agile CoP did do right is being very open about the numbers involved in the test process. Derek Huether is the new co-lead for the ACP support team and in a recent blog he presented the PMI-ACP Numbers. Very interesting to look at. While more than 7600 individuals started the online application, less than 1500 submitted their application and only 557 went the full distance and sat for the test.  I’ve copied Derek’s graph here for easy viewing.
I guess I’d always thought the number of people sitting for the test was much larger. I thought I was one of thousands and not one of hundreds. Certainly puts a lot more perspective on things and tells me that if I pass, I’ve got a lot of responsibility on my shoulders to help represent the new credential well.
So about the test itself:
In a direct comparison to the PMP test, the ACP is equal in complexity and demand on your raw knowledge. At the asame time if you are really Agile, the test is less demanding mentally. With the PMP what matters is the absolute answer, as determined by the PMI folks that crafted the test. If you are faced with a PMP question you have no knowledge on, you stand about 20% chance of getting the question right (the test usually has 4-5 answers). With the ACP, if you understand agile, then your intuition will guide you as much as your raw knowledge.
Studying for the test right now is difficult. Where the PMP has a single body of knowledge book, the ACP references around ten books, including at least one that has only been published this year. As much as I intuitively get agile, the level of detail needed to pass the test was daunting. At the end of the day PMI is giving a multiple choice test and there can only be one, right answer. If you have been doing agile for going on a decade or more then you’re probably have an experience similar to the one the Agile Scout had. If you like me and a project manager who discovered agile in the last few years, then you are going to have to study to know the material. It’s not that you don’t know agile, it’s just that there is a vast body of knowledge that is often very disparate.
I can’t help but wonder at the creation of preparation courses for this test. There is a huge scope of information to cover and it will be a challenge to do it in a way that isn’t a death by PowerPoint memorization class. Finding a prep course that is true to agile and will help you study will be a major challenge. And those of you who follow me regularly know how I feel about “pass the test” prep courses.
The Details: 
Before you ever take up the challenge to get this certification, you really needed to understand a few things.
Agile– Well, yeah! But seriously preparing for and deciding to take the ACP required a solid understanding of the spirit of agile. This goes to my recent blog and speech, which focus on the idea that the concepts of agile can be used anytime, anywhere. If you’re a Scrum purist who doesn’t see the need for Lean or XP and holds to a firm position on how Scrum should be done right, then pursuing a Certified Scrum Practitioner certification is probably a better use of your time. To want to take the ACP and to get value from it, you need to already be looking at agile from the holistic and people view.
The Value of Certification– Many a cynic has asserted that certifications are purely a means for some company or organization to reach deep into your wallet and fleece it. And you’d have to be pure-as-snow innocent to not think those organizations are not thinking about themselves. That does not invalidate the value of a well managed certification. In Potato, Pahtato I delved into one of the key benefits of a common certification, that of a common language. It also creates a common level of expectation or standards. If you hire an MSCE to fix your Windows network, you can have an expectation that he actually knows what he’s doing. Right now there is only the Scrum certifications as any common set of accepted proofs of agile competency.
It can certainly be implemented wrong and even the most altruistic bodies can go astray, one need only look at the Scrum Alliance to see how even the most agile can lose their way from time to time. But if the people who believe and care for that which is being certified, then I think it is their duty to help guide the process, from the inside. If I never became an ACP, I could only comment from the outside and my voice would the weaker for it. 
The Test Format- Going back to the understanding of agile, for a moment, one thing that is very important is the incredible breadth and depth of the concepts, tools and methodologies of Agile. It is all too easy for people to think of agile as just being ten years old, when its roots reach back at least sixty years and one could argue far beyond that.
So with that in mind, it could quickly be daunting to have a concept of just what you are going to need to know to pass the ACP. PMI gave this kind of guidance and it was invaluable in scoping out my study. Their Exam Prep resources give a starting point on not only how to apply but what to study. Knowing that questions about Agile Contracting was considered a Level 3 knowledge area and thus only 5% of the total exam meant I didn’t stress as much about my knowledge here. Brainstorming techniques, empowered teams and the Manifesto were areas I needed much more focus on as they were considered Level 1 knowledge, 33% of the test’s questions.
Let me start with a strong self assessment. As I dove into studying for the ACP  I had my doubts. Yes, I “understood” Agile but I realized my practical hands on experience was mostly limited to team dynamics. Diving into detailed estimating, for example, I had my doubts on if I had any business taking this test. If I hadn’t already had a test date set, I’m not sure my willpower would have pulled me through. Fortunately I did, and my will stayed strong. It’s was an important lesson in focus and belief in myself.
Which brings us to the studying. Eleven books is one hell of big body of knowledge. Even having read a number of these books previously didn’t lessen the massive amount of data to understand. Without the study guide it would be an impossible pile to tackle. Even with the study guide, it becomes a strong test of your knowledge. You can’t come into the ACP without having a very strong agile background or having read at least some of these books. It was one of my largest challenges, as much of my agile knowledge has come from doing and hands-on coaching styles. I had read some of the books already, but as I tackled the rest of the books it was downright intimidating. Just figuring out what book to read first was a major struggle. The Study Guide helped, but it was perfect as not all the books have nice cheat sheets on the cover declaring their focus.
So I reached into my bag of study tricks and pulled something out from my old PMP study. Sample questions. With a brand new test I knew it was a long shot, but Google came through for me. I found a website which had sample exam questions. The answers gave exact source where the answer came from and allowed me to focus on the areas I was weak. (Edit: Jan, 2012- At this time I can no longer recommend the service I had used, Agileexams. I recommend doing a search for PMI-ACP exam questions and finding an alternative service). Now this wasn’t a solution. This was not the way to pass the test, just pile through the test questions and BANG, you’re agile.
The real value of Agileexams  wasn’t the questions. It was the source citing. When you were given the answer to a question, they cited the book and section the answer came from. By taking sample tests I was able to then look at the questions I got wrong or fully didn’t understand and then assemble a reading list. Instead of having to read all the Agile books, I was able to focus on the areas I was weak in.
Other thoughts: ACP is much more than a CSP. The names pretty much cover it. The CSP is strictly Scrum focused. While it recognizes and draws on the core agile values, it does not recognize the other flavors of agile, does not have any focus on the chartering or closing of a project and definitely doesn’t look at hybrid agile models. The ACP is built on a broad level of agile philosophy, with a very strong amount of “do what works.” I imagine Scrum purists will  continue to the be the biggest detractors of the ACP over the long term, as it doesn’t wed itself to any one style.
The Test:
It’s a proctored exam, what more can you say? You show up for the test and the first thing you do is dump the contents of your pockets into a locker (This includes watches, eye glass cases and even the little shami to clean your eye glasses). Then you present your photo ID and they verify you are you. You’d better hope your license matches your application. After that you prove your pockets are empty and then you go to another room where they verify your identity all over again. And then they use a metal detector on you, just to make sure you don’t have a computer in your underwear.
If you pay attention during this part, you notice the bank of computer screens piping in video feed from the exam room. One camera per computer station and then ones that view large parts of the room. Yes, big brother is watching.
An important note is the supplies they provide. It used to be that you were given several sheets of paper and a pencil. These were key tools for me when I took the PMP. I spent the week before my test creating my memory sheet over and over. When I sat down for the test, I dumped it all onto the page. All the formulas, process flows, theories and so on. PMI is now having the exam centers issue you a fine tipped dry erase marker and three sheets of laminated paper. This greatly effects what you can put on a page and is something to keep in mind for what notes you want to put “on paper” at the start of your test. That said, I didn’t find this all that big an issue as there isn’t much in the way of formulas in agile. I did memorize the agile EVM equation, and wrote that down.
The test itself is a standard computer based multiple choice test. There is a wealth of comments on this  style of tests and advice for taking them (Always read the answers from last to first, for example). The questions themselves are in the style that anyone whose taken the PMP are familiar with. They are also very similar to the Agileexams.com questions. The similarity though shows the common roots of the source material. I’d say the Agileexam questions had a more relaxed feel that made them feel more “agile.” The ACP questions were very dry and focused, not having nearly as much team dynamics questions.
Post Test:
So I survived the test, now what? Well Disney Land is not in the budget, so I guess I’ll stick with writing down my thoughts and thinking about how I can help others understand the ACP and the value of agile.
I have to agree with Sally Elatta on the surprises I found in the test. Lean Portfolio Management, Risk Management in Agile and information radiators other than the common burn down and burn up chart were very prevalent. I came away from the test feeling I needed more knowledge on a few key areas. These were how long user stories are valid for, Lean portfolio management, Lean information radiators, Risk Audits in agile and Extreme Personas.
One very positive experience, I had in all this, was my post test interaction with Rory McCorkle, the Product Owner at PMI for the ACP. There was one question in the test that I had a real issue with. I felt the answer was misleading and didn’t hold true to the reasons agile came to be. I contacted Rory and he responded the same day. He thanked me for my input and said it would be added to the questions they would review in the Retrospective planned for December. This small interaction gave me a lot of hope for the people running the ACP at PMI.
Can someone just hit the books and pass this course? Absolutely, but that’s pretty much a given in any kind of certification. There will be people who get the certification just for the certification and won’t have a full understanding of Agile. I think it will be a smaller percentage than we are seeing in PMP tests. And I think it is the responsibility of the first ACP holders to help ensure the certification ends up with all the positive things about the PMP and none of the negative.
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

The contemplative gorilla: The value of retrospectives

Bang… Bang… Bang…
You know the nice thing about banging your head on the desk? It feels so great when you stop.
Bang… Bang… Bang…
The smell of banana proceeded the lumbering form that entered my office. “You’re gonna break the desk like that,” Hogarth said.
Just great, honestly I hadn’t done anything wrong this time. Why was he here? “Go away, Hogarth. Let me be miserable in peace.”
Hogarth slid a ripe banana onto the desk, preventing me from hitting my head further. Unless I wanted to make banana puree. “Come on,” he said, “you should take it as a compliment. The team blew away all previous performance records for delivery. The pointy haired bosses are breaking up the team to try and spread the love. You did an awesome job, be happy about it.” He pointed at my computer screen, “besides, you’ve got the project retrospective to go to. You don’t want to be morose in that.”
“Retrospective!” I snapped. “What’s the point of a retrospective? The teams’ being broken up. I’ll have all new engineers for version 2.”
“Huh…” Hogarth grunted. “Are we reviewing the product that was just built, or are we reviewing the project?”
“The project” I snapped. “We don’t need to review the product, we had 100% pass on acceptance tests and validated with management and the customer that they got exactly what they wanted.”
“That’s what I thought.” Hogarth said. “Let me ask you this. If your Kendo teacher only taught you lessons that wouldn’t damage the blade, would that effect your learning?”
“Wha? Of course it would. He teaches me things so I’ll be a better swordsman, the sword is the tool to learn with.”
“And so is the product…”
Agile Retrospectives: The keys to them are they are by the team, for the team and take action from them right away. No filing it away in a dusty file cabinet.
I had an interesting conversation on #PMChat . While discussing bringing projects back from red, we got into learning from mistakes.  The question was:
“Q4. In his post @backfromred discusses the concepts of a ‘learning culture’ for project success. What does that mean to you? #PMChat
Rob Kelly (@rkelly976) tweeted:
 ” Actually conducting a lessons learned session, archiving them, AND using them later .”
Sidebar: So if you only just tuned into the Hogarth channel, let me just remind folks of my position. I think that agile values and principles can be applied in any company and at any layer to make better teams, better products and better companies. 
So it is untestable that I responded to Rob with:
“Don’t archive them. Pick at least two things and start doing them right away. “
Ron Rosenhead (@ronrosenhead) also replied to Rob with
“BUT: research suggests that people do not read lessons learned …#pmchat relying ons something that does not work”
And I jumped back with:
“Which is why you action them right out of the meeting. That’s the #agile model for retrospectives. Don’t file.
Whew, enough tennis,  let’s get to a point!
Agile retrospectives have a major component to them that so many other Lesson’s Learned models lack. That is immediate accountability and action. When you come out of a retrospective, you should have a clear decision on changes to make changes and have the “Who, Does What, By When” documented. If you don’t make a decision and don’t turn it into action items, then you get what Ron laments, a filed document that no one reads.
Now Rob came back with a great question.  I had a glib answer for at the time, but one that really got me thinking. He asked: “What about heavy contractor/turnstyle orgs?”
He raised a great point. There are many industries that roll most of the team every release. If the company is failing, some of the team might be let go. If the project was a success, some of the team is promoted. So what happens to the team? What happens to the collective knowledge?
What’s the point in doing an immediate results retrospective if there is no one left to enjoy it?
As fate would have it, I have just been reading Agile Retrospectives, by Esther Derby and Diana Larsen. I read the last chapter today, after the PMChat, and found these words of wisdom.
“Even when the team doesn’t stay together, people take that learning with them to benefit other teams and other projects.”
Agile spends a lot of time looking at the team and sometimes we can easily forget that teams are made up of individual people. These people have their own career paths and arcs that will take them on varying courses over time. And that’s okay. Remember, this is the 21st century. This is the century I think will see project managers becoming the new “people manager.” In an era when few companies look after their employees careers, it falls to individuals like the project manager to help coach and guide the people on their teams. This goes to one of my core principles, that if you focus on the team, the product will follow.
If our focus is on the team, then we should exult when they are tapped for new projects, new promotions, new jobs. Manager Tools maintains that one of the best measure of a manager’s success is that they get their people promoted.
Instead of focusing on how the project will be impacted, recognize the value the team will get from that final retrospective. What lessons will they learn and take with them? How will this benefit the company, the industry, the world? Better teams are made up of better people. And a better world is made up of better people.
You do the math…
And if that wasn’t a compelling enough reason, think about the benefit to the company as a whole. From the same paragraph of Agile Retrospectives.
“Release and project retrospectives uncover organizational factors, policies and procedures that get in the way of the team – and these require coordination across areas to solve.”
Taking it back to being all about “Me.” If you have to go off and two version 2.0 of the project, the best team in the world isn’t going to matter if the supply chain looks more like a supply thread.
No matter what happens after the project, a retrospective will help all those involved to be better on the next team and the next project they are on. Better teams, make better projects.
You do the math…
Joel Bancroft-Connors
The Gorilla Talker
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

No one expects the Gorilla Retrospective

Jake was pinned to his seat by the spotlight’s intense beam. “Where were you when the code check-in introduced four P1 bugs?”

“I, uh, what?” Jake stammered.
I spun the spotlight and speared Bob with its white light. “The requirements document failed to take into account the Fergusson account. Why?”
Bob shifted in his seat. “It was Jane’s fault, she didn’t file a sales report for Fergusson!”
Jane’s mouth dropped open and she reached for her cellphone. Somehow I didn’t think she planned to text Bob with it. Not from the way she was holding it over her head.
Now I was getting somewhere. This post-mortem was finally getting to the bottom of things.
But before I could turn the spotlight towards Jane, a figure leaped onto the table and blocked my view. Jumping back, I looked up at the strange visage before me. Yards of red satin swirled about, all but obscuring the figure beneath it. A red galero covered the figure’s head, its deep crimson so dark it nearly blended with the black hair that lay beneath it. The darkness of satin and hair offset the brilliant white teeth of my interloper, making him suddenly recognizable.
Hogarth struck a preposterous pose and declared, “No one expects the Gorilla Retrospective!”

The Post-Mortem:
If you have ever sat through a grueling multi-hour project post-mortem, you probably wished for the inquisition to sweep in and put you out of your misery. The very term means “after death.” What a delightfully pleasant term for this meeting. Let us examine the corpse of the project and see what killed it. Let’s not trouble ourselves with the fact that the project actually shipped and is a success. No, that would be pointless.
The purpose of the meeting is to tear apart the project and find everything that went wrong. As the project manager, you will assemble a mammoth document that goes into sickening detail. Even if you tell people “we aren’t here to blame anyone”, blame will be assigned and buses will be thrown on top of people (or something like that).
And when it’s all over, the report is dutifully filed in some file cabinet (real or virtual) and promptly forgotten. No one goes back and reviews it. No one wants to remember the painful experience of exhuming a successful project for failures.
A rose by any other name:
Okay so we won’t call it a post mortem. How about lessons learned or a retrospective? Yeah, that’s the ticket. Now who’s fault was it that we shipped with no user documentation?
You can slap lipstick on the pig and it will still be a pig. Changing the name of something, but not how you go about doing it, is just going to make folks dislike the new name as much as the old.
So many companies look back on their projects to find what went wrong and fail to try and do better the next time.
Break off that rear view mirror:
I’ve met no small amount of people who think the George Santanya quote “Those who cannot remember the past are condemned to repeat it” means we have to live in that history. Relive every mistake and wrong to determine exactly why it happened.
Not so. The horses are already out of the barn. Grilling the ranch hand on why he left the door open isn’t going to do much. It doesn’t get the horses back and it doesn’t really do anything about the future. Manager Tools recently did a podcast called “There is no why in feedback.” The Feedback Model is a manager tool for communicating about both the good and not so good things your directs do. The big key to it is that it doesn’t focus at all on the past behavior. It just focus on the future.
 An example:
“Don, can I give you some feedback? <wait for answer> “When you are late to the meeting, we start late and can’t finish the agenda. This means not everyone gets a chance to be heard. Do you think you could change that next time?
Read the last sentence again. “Next time.” The manager doesn’t dwell on the previous issue, instead he dwells on it not happening again.
And that’s the secret to a great retrospective. Focus on the future. Don’t assign blame. Don’t dissect every problem. Don’t get lost in the spilt milk. Focus on doing better the next time.
Forward looking:
When I do a retrospective I pull out another tool from my Manager Tools bag. On the left side of the white board I write “What Went Well.” On the right side I write “Things to Look At.”
The latter is important and I always stress it. TLA isn’t about blame, it isn’t about why, it isn’t even about negative. It is simply things we want to look at for the future. This can mean you end up with things people would generally refer to a “positive” on the Things to Look At side. After a good retrospective, I often have lines drawn from items on the WWW side to the TLA side. Things that were not part of the normal process, that had a good impact and the team wants to do it again.
The next step is to lay down the brain storming rules. When using the brain storming rules there is no “No”, “But”, or “I don’t agree.” Brain storming is a safe zone where anyone can throw out anything and there will be no discussion, no argument and anything goes. If someone yells out “Pepperoni Pizza,” my only response is “Is that a ‘Went Well’ or a ‘Things to Look At’?”
When you’re done collecting your WWW-TLA you then give everyone something to vote with. Small teams can use markers, larger teams work well with stickers or even post its. Let everyone vote two or three times on the TLA side. Then you tally up the votes and you’ve got your top things to look at changing for the next time. Short, sweet, to the point and very effective.
Don’t make your retrospectives a full court trial. Don’t dwell on the past. Do make it safe for people to reflect. Do focus on the future.
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP