Certifiably Gorilla- A retrospective of the PMI-ACP

Note: For new Gorilla Blogs, head over to The Gorilla Coach

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:

Summary: 

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: 

Understanding:

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.

Study:

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

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

The Gorilla changing room- Making decisions out of choices

"WAIT, WAIT, What?"

Bob hasn't been handling stress to well lately. His last word broke into a near falsetto and the tick above his eye was threatening to register on the Richter scale.

Monica didn't seem the least phased by the outburst. I think it would have taken a good 9.0 to shake the plastic smile from her face. "Marketing thinks Pantone Snorkel Blue 19-4049 is not the right shade for the logo on the case. We want to look at Dark Blue 19-4035 instead."

Okay, so I have to admit Bob was probably justifiably upset. Me, I was having an odd sense of déjà vu.

"Excuse me, Monica, but didn't we go over the logo color about three weeks ago and all agree on Snorkel Blue?" I asked, trying to give poor Bob time for his blood pressure to get back down under 200.

Monica gave a casual wave with her absolutely pristine fingernails. "Well, yes, but marketing wasn't sure then so we didn't say anything."

If Monica kept talking in the third person I might just snap myself. "Okay, we are starting mass production in a day. I'm not even sure we can change the color. Wally?" I turned to look at the head of our hardware team.

Wally looked at me with a pained expression that didn't need words. If they had words, they'd probably been something like "I've had our manufacturer change the blasted logo color seven times, how many more do you want to change it?"

Monica gave a dismissive wave to Wally. "Marketing feels certain that the color has to change, can't you just speed up the shipping process to cover?"

Bob leaned forward, smoke veritably curling from his ears. "We already chose the color, five times. If you can't be bothered to attend the meetings because you are to busy getting your forehead botoxed…"

Hogarth sidled up to me, his hot breath on my neck the first clue I had to his nearness. Thing is I wasn't surprised. The meeting was going just so many different ways of wrong that I knew he was bound to show up sooner or later. I guess you could say I was starting to learn and understand his presence. His appearances were no longer absolute surprises of non-sequiturs.  I could almost hear the lesson he was about to give.

"So does this make you Bill Murray?" he asked.

Blink… Huh? Blink… Blink… That was not the lesson I was expecting.

I turned away from Bob's latest fusillade at Monica and stared at Hogarth. His brilliant white smile was in counterpoint to his bushy black eyebrow raised at me in question. Sometimes I think he truly takes pleasure in confounding me to speechlessness. "Hogarth, what on earth are you talking about?"

"Groundhog day of course. You know, the film with Bill Murray reliving the same day over and over until he gets things right?"

"Hogarth, it's not February, I'm not Bill Murray and what the hell does this have to do with the meeting."

"Well didn't you already decide on the color of the logo five times?"

"No, it's been seven…" Hogarth just looked at me.  "Oh, hell."

There is a malaise sweeping business, from San Francisco to Sydney and Johannesburg to Edinburgh the same problem is rearing up to prevent companies from succeeding, from moving forward, from getting anything done, from not killing each other in meetings of death, from doing the right things, the right way. What is this frightening cancer? What is this thing that is able to crush your projects and leave the teams wondering what was the license plate of the bus they were just thrown under?

We can't make decisions… To be clear, we are very good at picking choices. We are wonderful at nodding heads and saying "yes" but we are absolutely abysmal at making and committing to decisions. When it comes to putting the rubber to the road, we are found to be lacking even the tires needed to hit the road.

Wait a minute. You just said we are very good at making choices, what's the problem?

A choice is not a decision: A choice is picking someone to ask to prom night. A decision is saying "I do" to marry your spouse. When you go to Baskin and Robbins (A US based Ice Cream store) there are thirty-one choices of ice cream, but there is only one decision as to what you'll get on that single scoop. A decision is a stake in the ground with clear accountability tied to it.

Accountability… There's that scary word again. Don't run away, it won't bite. Accountability is easy. It can be fulfilled with Mark Horstman's single law of project management., "Who, Does What, By When."

You see, what so often happens is that everyone is sitting in the room and a plan is developed. People nod their heads, and maybe the guy who was really opposed decides now is not the time to object. But then there is no follow up. Sure it might have gotten documented in the meeting minutes, but no one was assigned ownership. No date was set. No specific plan was set. How do we know if it is done? How do we know if what was agreed is what is being done? How do you measure the "acceptance criteria?"

If a choice was made, you don't. If a decision was documented then you have.

Hey now! Don't run scared just because I used the "D" word. Documentation does not need to mean a twenty page requirements document. Documentation just needs to be "Who," "What," "When." The only hard part is the what and if you define what by the acceptance criteria it can be pretty darn easy.

You have the power! Stop the déjà vu cycle! Don't go through another Groundhog day again. Don't let a meeting end without "Who," What," and "When" being written down and agreed to.

Change isn't a bad thing. But changing because you didn't agree the first time is a waste.

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.

The contemplative gorilla: The value of retrospectives

Note: For new Gorilla Blogs, head over to The Gorilla Coach

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

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

The Winning Gorilla: A Book Review of "The Lazy Winner"

"Yeah, sure no problem. I can get that done."

I hung up the phone, a cheerful smile on my face, and turned back to my computer. Only to be faced with a staggering to do list awash in the red of late deliverables. Why the heck did I just say yes to another deliverable? I was already behind on a half dozen and the list of commitments just for this week was enough to keep me busy through to the new year. What was I thinking?

"You weren't"

Sigh… And here comes the gorilla to tell me the error of my ways.

Hogarth perched on my desk, causing it to groan in protest at this 800 pound bulk. "There's a wonderful word in your English language. You might be familiar with it. It's the word 'No."

"Yeah, yeah I know about no."

Hogarth pointed his banana at me, "But do you know how to use no?"

"Of course I know!"

"Really? Can you tell me the status of the Glitteratti regression testing?"

"At this time QA has not published their report so I don't have an up to date status."

Hogarth shook his head, "That didn't sound like a no. Way to many syllables. What's the status of the Glitteratti regression?"

I gritted my teeth, "I don't have that status right now, I should have it…"

Hogarth waved his cantaloupe sized hand in front of me, "You know, never mind. I actually came in here to ask if I could borrow your car. I saw this great move on an old Dukes of Hazard that I want to try. So can I borrow your car?"

"NO!" I replied without thinking.

Hogarth smiled broadly. Leaning over he patted me on the shoulder, "see there, I knew you could say no!"

BOOK REVIEW: The Lazy Winner, By Peter Taylor

It's not often I'm on the leading edge of a book. It took me close to twenty years to read 7 Habits and my last review was on the ten year old Good to Great. So the ability to read a book when it first comes out is something I take as a great joy.

Now I do need to give the disclaimer that I didn't pay for The Lazy Winner. I received a complementary copy with the agreement that after reading it, I would write a review for it on Amazon. That said, being the gorilla talker means I'm not about to pull punches just because I didn't pay the cover price.

Summary:

The Lazy Winner steps beyond Peter's first book, The Lazy Project Manager and seeks to provide helpful guidance for anyone trying to survive the daily grind of professional life. The Lazy PM was chock full of useful tips and techniques for the project manager and still sits in a prominent spot on my desk bookshelf. The Lazy Winner is both targeted at a wider audience and more narrow in its approach.

The book is strictly focused on you and how you can succeed in the work environment without killing yourself. And it is not a book that tries to promise the world. In fact Peter spends the first couple of pages trying to convince you not to read the book. You have to want to change to change.

The key to the book is five questions and then how you answer and define them:

Do I want to do this piece of work, job or task? Even if I do want to do it, do I need to do it?

Is the potential result or outcome worth my effort?

Do I have to do it myself?

If I have to do it then what is the shortest path to the point of success?

What exactly is the point of success and at what stage will I just be wasting time?

Revisiting the Pareto rule, which he first references in The Lazy PM, Peter then uses these five questions to help the reader learn how to channel what he actually does to the most important and value added items. And unlike many self help books, in this vein, he doesn't try whitewash away the stuff you don't do. There is a large factor to ensuring things don't get dropped, even as you do less, but more productive work.

Peter even talks about the inertia against change. "But it's so easy to just keep doing it this way…" Using some of his signature simple graphics he walks the reader through how to examine the value of change versus not change.

The Good:

This makes sense: Peter has a conversational reading style. Having listened to his podcasts, I could easily imagine him reading the words to me. He mixes a simple writing style, humor and just the right amount of formatting to make The Lazy Winner the kind of book you say "I'll just read one more page and then I'll put it down."

Questions of power: I've understood the Pareto rule and I learned the hard way I don't have to do everything myself. And even with that under my belt, the five questions make a wonderful level of sense and will be something I refer back to time and again.

Footnotes of laughter: Read the footnotes. I usually am one to skip footnotes as way to much detail but you'd be the poorer if you do that with this book. Read the footnotes for the information but more importantly for the humor.

The Bad:

Just a snack: The PDF copy comes in at just 162 pages with the Appendix (a very useful appendix) starting at page 121. Peter packs a fair amount into the book, but I can't help but feel I'm reading the cliffs notes of summary copy of the book. Everything section left me looking for more. Then again, perhaps this was on purpose. If you give to much help in a self help book, people might not think for themselves. In the end, like the Chinese food Peter loves so well, this book left me hungry for more thirty minutes after finishing.

I'm ready for my close up: I love the cover to The Lazy Project Manager. It is simple and compelling. The kind of cover that catches your eye on a bookshelf or in an e-catalog. While the photo of Peter is a good one, I think it would be a lot better as the "About the author" picture. A laughing man, not looking at the camera doesn't sell me "Winner." If I didn't know who Peter was, I might be inclined to say "Wow, what an ego, he used his own face." I'd rather see art in the same style as The Lazy PM. A stylized checkered flag over a man racing a desk or something.

Ow, ow, my wallet: $23 US for the print edition of the book feels a little steep. It’s a smaller book than his first and still going for a similar price. Perhaps I'm just out of touch with prices but if I were to heft the print version, in a Barnes and Noble, I'd think it didn't weigh what a $23 book should weigh. The Kindle version though is $9.99 and that's in the reasonable (for Amazon) e-book range.

The Bookshelf Index:

The Lazy Winner won't be joining The Lazy Project Manager on my desk bookshelf. It has some valuable insights, but the core meat are those magic questions and a couple of other points. I'll be creating a one page of those to pin on my wall and the book will be filed away in my reference stack.

Well worth the read, but not something you won't be reaching for again and again.  This book is perfect for electronic reading. Short, easy to read and you won't be wanting to flip through the pages to refer to it like you might with The Lazy Project Manager.

NOTE: Passing on a shameless plug from Peter Taylor. The Lazy Winner is currently (Dec 14, 2011) free on the Kindle in the US Amazon shop. Take advantage of his largess while it lasts.

Joel Bancroft-Connors

The Gorilla Talker Project Manager

Want me to talk to your gorilla? Send me an email

You can follow me on twitter, @JBC_PMP

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

Gorilla Review: Rally's Agile Portfolio Management Product Launch

Note: For new Gorilla Blogs, head over to The Gorilla Coach

On December 6th, 2011 Rally held the first launch event for their new Agile Portfolio Management product. Hogarth and I were there.

My fingers were flying at the speed of bad bugs appearing in legacy code. The darkness of the room barely slowed me down and I mentally gave a thanks that my keyboard was so silent. I'd be caught up with the project plan by the end of the presentation at this rate!

"Isn't this your project the Engineers are pontificating on?"

Curses! And I was getting so much done. I turned to peer into the darkness beside me. Only Hogarth's gleaming teeth were clearly visible in the half light from the projector screen. "Hogarth I don't have time. If I can get this report done while they present, then I'll be able to report all deliverables for the project are on track."

Hogarth lounged back in the chair picking his teeth with a fragment of branch. "So tell me, I thought you were running an Agile program?"

I sighed. I've tried ignoring him in the past and it never worked. Giving up I turned to look at him. "We are."

"Uh huh, and you're in the process of filling out a hundred line detailed feature matrix why?"

"Because I still need to be able to track the details, but we're running Agile for the work. We have sprints and everything."

Hogarth nodded sagely. "If all the street signs are in Polish, there's pretty good odds you're in Poland."

"What?!"

"In other words, methinks you doth protest too much."

EVENT REVIEW: Rally Development Agile Portfolio Management Product Launch

Summary:

You can't get a much nicer venue than the Rosewood Sand Hill. Anyone who knows Silicon Valley, knows Sand Hill road is famous as Venture Capital alley. So it stands to reason that the hotel on Sand Hill is one of the most elegant facilities you will find. As I trekked from the outer parking lot I first passed the black suited town car drivers, huddled in conversation as they waited to whisk their businessmen off to the airport. Crossing the cobblestone courtyard I passed a Porche 911, Mercedes McLaren, Bentley Continental and a half dozen other who's who of the Top Gear cool wall cars, each one more costly than my entire annual  salary.

It certainly set  the tone for an event Rally is billing as their "first product launch." The company clearly set out to make this an event to remember. Something to be said as this was the first of three such events to be held across the US. The hotel was the back drop for an elegant European style breakfast buffet and a ball room that I could easily picture dukes and duchesses promenading across in a grand march. Technology was certainly not lacking, either. The hotel itself gets another nod for the concealed projection screens and projectors that slid from the ceiling at the flick of a remote. The entire event was broadcast as a live web event, but not just any conference call webcast. The entire back wall was a mass of audio visual equipment and personnel, including two fixed cameras and a roving camera operator.

This free event was well attended, for the size of the event. I would say the number was between 65 and 75 participants with probably a good 15 Rally folks to see to their every need.

The venue was grand, the technical setup perfect and the Rally event staff was on top of things. That just left the content. With swings up and down the scale, but mostly on the up, Rally hit this ball for a good solid triple. I'm not prepared to give it a home run, but it came close.

Ryan Martens, Rally founder and current CTO, opened the event. He was skillful in establishing his and Rally's bona fides without coming off as gloating. No mean feat when he talked about his presence at the Agile Manifesto 2011 reunion.

Getting Crossing the Chasm author, Geoffrey Moore, as the keynote speaker was an excellent choice. Speaking from the principles of this new book, Escape Velocity (every attendee got a free copy), Moore both outlined how he envisioned the power models of a successful company and tied it all back to Agile and Agile Portfolio Management. I'm certainly looking forward to reading the book, but the key take aways I've already picked up are gold in themselves. His description of Offer Power - Differentiation, Neutralization and Productivity  - opened my eyes to some components I know I've been missing in my own Gorilla Philosophy. Getting outside the yellow circle to be different and "good enough, quick enough" are key concepts I walked away with.

From here Todd Olson, VP of Products, got up to demonstrate the new product - it was a product launch after all. At its core, Rally's portfolio management software is pushing into the "game changing" category for Agile software. This wasn't an attempt to reskin existing product and cram it through the square hole to fit. The software is aligned to the idea of "Do the right things" as opposed to project level software which focuses on "Do things right." There seems to be a fair amount on customization capability that will allow users to morph the product to fit their project. I did have some concerns and confusions but in the spirit of agile, "Done beats perfect" and this product is certainly done.

Nina Schoen, of Getty Images, provided the customer testimonial. She walked us through Getty's process of getting control of their roadmap and portfolio. The success of the roll out was so good that their marketing department has started using it and the task level kanban process.

The session was capped by a panel Q&A session. Here I came away with two key things. First is the name Dave West of Forrester Research. He's a strong voice for Agile/Lean/Commonsense and not afraid to use his British wit and irony ("Our customers don't want rapid releases from us?" "Maybe because your product is awful") be to drive his points home. Rally certainly thinks highly of him as he'll be their keynote for the Dec 8th event. The second is the simple reminder to not let perfect be the enemy of good. Or in this case, just start doing, improve as you go.

The Good:

I already highlighted a lot of the good points in my summary, but let me hit a few stand outs.

• Geoffrey Moore's presentation style: He's got a sharp wit, a great presence and a passion for his topic. A joy to listen to.

• Technical setup: I don't know who the AV company Rally hired was, but they deserved a bonus. Everything ran smoothly.

• Wired and ready: They didn't just prepare for social media, they promoted it. Every slide had the events hashtag, wireless was provided and every Rally speaker gave their twitter handle as part of their introductions.
• Did I mention Geoffrey?

The Bad:

I'm a project manager, I look for problems, I get paid to. My wife is also a professional event planner, so I've learned to see even more.  

• Point the way: Rosewood has a policy of clean lines and uncluttered elegance. Because of this, they don't have signage up. That's fine, but make sure the concierge knows where your registration desk is.

• Timeboxes keep on slipping, slipping, slipping: We lost some good QA time at the end for lack of good time boxing. Also, the post lunch break out sessions were only 45 minutes, not the hours advertised. Call a spade a spade in the agenda and list the meeting close as its own topic.
• Hash marathon: #AgileNewLevel was the hashtag. I've only got a 140 characters to work with. Taking 14 of those away for a hash tag longer than the Titanic cuts into my ability to Tweet. Keep it under ten.
• Just the facts ma'am: During Todd's speech he showed off their timeline visual tool. It looks a lot like a Gantt chart. That's fine, for the purpose of the tool it works great. What didn't was his quote "Not a Gantt chart, this is based on facts, real data." Gantt charts are just the visual output of data. It doesn't care of the data is real or not. A well run Waterfall project has a Gantt chart based on "real data." Agile doesn't have the lock on that.

• Feature fixation: My biggest gripe with the new product was the use of language. They did a great job of using "Goals" at the highest level of the portfolio track. Unfortunately the next level down they switch to "Feature" and even go so far as to "assign a feature to a product owner." Ouch…

Words are very powerful and can create entire preconceptions. When I say "I met Sandy today," the image most people get is that of a woman. Sandy just isn't a common man's name. When you use the word feature, my experience is that people naturally tend to move to the "how" and not the "what." We lose sight of the user story and focus on a specific implementation. One sample "feature" Todd created had to do with setting up USPS priority shipping functionality. That's a feature, not a user story. A lot of Product Managers have enough issues with understanding how to focus on the value, without giving them a tool that lets them easily fall into old habits.

• Put the laptop down and no one gets hurt: The meeting is in full swing, the CTO is expounding on the dedication and focus of Rally. He's selling us all on the company. And while he's doing that, a good half the Rally staff was along the back wall of the room Mac Books open or doing the Blackberry prayer.

Seriously? This is supposed to be one of the most important events in your companies ten year history and you can't put down the computer for a couple of hours? Yes, someone was monitoring the online attendees. That needed to happen. Go sit at the huge AV table with the other AV folks where you are invisible. But it didn't take ten people to monitor online attendance. While the Rally CTO, Mr. Moore, Product VP, and distinguished customer were expounding on Agile, the back of the room was busy checking emails (I hope they were checking emails, if someone was playing Angry Birds, for shame).

If work is that important that it can't wait, leave the room. If you are in the room, put the computer down and give the people on stage the energy they deserve. I can say that for me personally it made me have second thoughts about the dedication of the company if they can't focus on one thing for three hours.

Final Call: If this were a book, I'd give my bookshelf index now. But its not and this is the first event I've ever reviewed, so bear with me as we find a standard closing measure. I'm certainly interested in Rally's software and will likely check it out in more detail. I'm impressed with their events and would attend another. I worry about the product's focus on more waterfall terminology and I really didn't like the emailing wall.

Joel Bancroft-Connors

The Gorilla Talker Project Manager

Want me to talk to your gorilla? Send me an email

You can follow me on twitter, @JBC_PMP

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

Methodology roulette, always bet on Gorilla

Note: For new Gorilla Blogs, head over to The Gorilla Coach

This blog originally appeared on PMChat.net. I heartily recommend this site and more importantly the weekly Twitter chat that Rob Kelly and Rob Prinzo host with the hashtag #pmchat. Thanks again to Rob and Rob for inviting me to speak in the PMChat pre-game call and to share this blog on their site.

“Hogarth?”

My mind was still trying to comprehend the scene before me, but my mouth already knew who was undoubtedly responsible. The conference table was gone; in its place was a roulette table. Gathered around the betting section of the table were some of the usual suspects, Percy – the pink elephant, Wanda – the black swan, the apes Stanley and Winston, and even James – the intern.  And overseeing the table was none other than Hogarth. Wearing a poker visor and sweeping up chips with one of those crooked neck poles you see in gambling movies, he was cheerfully laying on the “dealer” patter.

“Winner pays to six phase lifecyle on black. Oh, tough luck for Wanda betting it all on Scrum red. Lay your bets for the next spin…”

Hogarth, was the gorilla in the room. He’s one part elephant in the room – that problem everyone is trying so hard to ignore, and one part 800 pound gorilla – something so powerful that it can act without regard to the desires of others. The gorilla in the room can crush your project into dust and leave your team wondering what the license plate number was of the bus they were just thrown under.

Like Harvey, Jimmy Stewart’s imaginary rabbit, Hogarth is my personal management Pooka. Thing about management Pooka’s is they are a blessing, a curse and totally unpredictable.

“Betting is closed,” Hogarth said. “Round and round she goes, where she stops nobody…”

“HOGARTH!” I snapped, this time much louder and with a healthy dose of annoyance. “What on earth are you doing?”

My 800 pound gorilla looked up from the spinning wheel. “Oh hey there, Boss. We’re just playing a little methodology roulette.”

I shook my head, trying to comprehend what he was saying. The roulette wheel was slowing down now and as I stepped closer I could see words, not numbers on the red and black pockets that made up the wheel. I caught words and acronyms like “6 Phase SLDC, 9 Phase PLC, Scrum, Lean, PDD, PUD, and BDUP”

“Methodology what?”

The table broke into groans of disgust as the ball finally fell into a pocket labeled “SotP.”

Hogarth turned to the table, brandishing his chip collecting stick. “Oh too bad, no one put anything down on the “seat of your pants” methodology.”

Hogarth pulled out the banana tucked under his sleeve garter. While he peeled it he addressed my question. “If you haven’t noticed, there is a hell of a lot of methodologies running around. Just here in the company you’ve got at least a dozen variations. Your using a Scrumish model in the consumer group, IT is using a Lean Kanban model, Finance has a customized accounting focused process for all projects it takes part in, and let’s not even get into what it takes for the hardware team to change a single resister from 10 to 15 ohm in that monolith, twelve gate process they have.” Tossing his banana peel in the trash, he continued around a mouthful of the fruit, “With all those different processes it plays complete havoc on anyone who wants to run a project. What the heck should they learn, PMP, Prince, Six Sig, Agile, IBM’s custom process, Accenture’s?” He shook his head, “Man could go crazy trying to figure out which process to become an expert on.”

He was right, absolutely dead right. I could feel my heart start to quicken with impending panic. What should I do?

“Oh come now, you don’t think I’d leave you hanging, now do you?” He gave me a sparkling white grin and pointed at the table. “When you can’t beat the house, don’t play the game. Remember it’s not about the process, it’s about the people.”.”

It’s good to have a Hogarth… (just don’t tell him that)

Methodology Roulette- Or how the heck can you work in any project?

We are hearing more and more about the portability of the project management skill set. I’ve blogged about this in previous blogs, “Project Gorillas are SMEs” and “The gorilla with too many hats.” The nutshell concept is that the project management career has become its own expertise that can transcend specific industries. I’m a walking, talking example of this, having worked in such diverse industries as hard drive manufacturing, consumer electronics, computer games and virtualization.

“Okay, so I believe I can work anywhere. The question is, how do we keep up with all the ways to run a project?”

Even within a single “big bucket” methodology (which is really the wrong term at this level, but that’s another blog) there are dozens if not scores of variations. I’ve worked in traditional “waterfall” (Plan Driven Development or Big Design Up Front) projects that range from a bare three phases/gates to a staggering nine phases/gates and I’ve heard of programs with even more gates. The blog Leading Answers has a great blog on Agile Adoption that shows a periodic table of agile adoption. If there are that many ways to adopt agile, just think of the number of ways to do agile.

PMBoK, Prince2, BDUF, PDD, XP, SCRUM, LEAN, AGILE, SIX SIGMA, PMP, CSM, ACP, AAPM, CSP, CPM, ABC, 123, PDQ, the list of methods and certifications is staggering. PMI alone has six different certifications, five of which are focused on their own specific methods and practices.

“Oh my head, there’s no way to keep up.”

That’s right, so don’t even try. Instead focus on what’s most important.

There is one thing every project I’ve ever worked on possessed. One constant factor across a half dozen industries and even more job titles. It’s on every project and it’s what you should focus on.

“You mean people?”

Right! You see for me I’ve come to the realization that it’s not about the methodology at all. To paraphrase presidential candidate, Bill Clinton, “It’s about the people, stupid.”

Projects are done by groups of people. And when a group of individuals works together, instead of in parallel, they become teams. And through teamwork the end result can be greater than the sum of the parts.

And that’s why today I call myself an “Agile Project Manager”.  Using the principles and values of agile to guide how I work with any team, any project, any methodology.

(Remember, agile isn’t a methodology. Just like the PMBoK isn’t a methodology, but a set of best practices, agility as it is practiced is nothing more than a set of guiding principles set forth in the Agile Manifesto. Scrum, XP, lean, those are methodologies).

The very first value of agility is “Individuals and Interactions over Process Tools.” It has nothing to do with the tangible. It has to do with how the team should function. Principles four, five, six, eight, and twelve are directly focused on people or team interactions and principle eleven can't happen without a motivated team. Agile isn't about shipping software, but instead is a set of values and principles. Values that have an extreme focus on the who, not the what.

“But Agile is just a passing fad, it won’t last.”

Agile the word is new, the concepts behind agile are not. Agile is new vocabulary for good business practices that go back to post World War II with Edward Demmings, the Toyota Production System, and the people philosophy that became the Toyota Way. It really goes back even further; to the Hawthorne Study in the post depression and the roots of Industrial Psychology  in WW I troop assignments. The point here is solid team building practices have existed for a long time. In the 1980’s and 90’s it seems we lost the way. In the drive for more efficient companies we forgot that the people in them are what make the products, not the balance sheet.

Using Agile as a management technique makes sense and is something that’s been done for decades. I’m not doing anything new, I’m just coming full circle.

“Umm, okay. So how do you do Agile without using Scrum (or Lean, or Kanban, or..)?”

There are many ways to do this.  Author and agile coach Lyssa Adkins focuses on coaching the players. Agile fundamentalist, Tobias Mayer, ascribes to total self-empowerment of the team. The Manager Tools  podcast series focuses on making you a better manager with the concept that making a better you makes a better team. You can follow one of the existing concepts or, like me, you can develop your own principles and guides. For me I focus on how I can help teams. By being the best team helper I can be, I support the team in being better.

At the end of the day the core concept here is to focus on the team. A better team, makes for a better product.

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