My PMI-ACP Exam Experience

Because I wanted to ensure people taking my class were learning things that are actually on the PMI-ACP exam, I thought it necessary to actually take the test.  Sure, I was an independent reviewer of the PMI-ACP content but I was not part of the team who wrote the exam.  Let me just say, I think those who wrote the exam did us all proud.  I know it sounds sick but I really enjoyed taking this exam. It wasn't too hard or easy.  For a v1.0 exam, it's pretty darn good.  If you've been leveraging Agile for several years, I think you could pass it (in its current form).  Let me caveat that by saying you'd have to be properly leveraging Lean, XP, and Scrum for several years.  In all seriousness, there are people who still think cowboy coding or having no formal process or documentation makes them "agile".  This exam pays its respects to the values and principles of agile practices and to those who wrote the Agile Manifesto just 10 years ago. Now, considering every exam will be different, you can't take my testing experience as gospel to prepare.  But, you can focus your attention in certain areas.  I'm pretty certain I won't upset anyone with this blog post.  I'm not exposing any super-secret strategy to game the exam.  I remember taking the PMP and getting frustrated because I felt like the goal was to trick me, not test me.  Thankfully, the PMI-ACP is not crafted like the PMP.  It's written in a tone an everyday Agilist will understand.

Here is my bullet list for public consumption.  The rest I will reserve for my PMI-ACP classes. (shameless plug)

• Know the Agile Manifesto Values and Principles.  Understand them.  Don't just memorize them.

• Have an end-to-end understanding of Scrum.
• Know and understand the key roles of Scrum.
• Know and understand the artifacts of Scrum.
• Understand what are and why we use big visible charts or information radiators.
• Be able to read a burndown chart and offer a few scenarios that would explain its appearance.
• Understand all of the Scrum meetings.  Who is there? Why? What happens and when?
• Understand Scrum from a ScrumMaster perspective.
• Understand Scrum from a Product Owner perspective.
• Understand Scrum from an empowered Team perspective.
• Know and understand the XP (eXtreme Programming) roles and who does what.
• Understand Test Driven Development. Know how it works and why it's valuable.
• Understand Continuous Integration. Know how it works and why it's valuable.
• Understand the Lean Software Development Principles
• Know what Lean Portfolio Management is and how your organization could benefit from it.
• Understand what Value Stream Mapping is and how to do it
• Understand the basics of Kanban
• Understand what WIP is and why it works.
• Know what Osmotic Communications is.
• Understand what makes a Servant Leader and what they do.
• Understand Velocity and it's usefulness.
• Understand Risk Burn Down Charts
• Know about Risk Audit Meetings
• Know Agile Estimation techniques
• Understand the Definition of "Done"
• Know how to write and identify good User Stories.
• Know what Personas are and how to use them.
• Understand why and when you would use AgileEVM (don't worry about how!)

Remember, you have 3 hours to answer 120 questions.

Good luck!

My AgileDC 2011 Session

AgileDC has come and gone but not without sharing memories with old friends and new.  It was great to meet Rory McCorkle of PMI, Howard Sublett of Big Visible, and countless others.  Peter Saddington (of AgileScout) and I even had a chance to hang out, go out for steaks, and have a few drinks. I have to say, AgileDC was a great event.  It was sold out and I scrambled to get tickets for my PMI-ACP learners.  There is something very cool about conferences.  Everyone there has something in common.  Foolishly, I thought I had to pick between the PMI Congress and the AgileDC event.  Jesse Fewell proved that it can be done.  Since we haven't had a chance to meet up face-to-face since the PMI NAC 2010, it was great to catch up a little.  As long as the PMI Congress 2012 is not scheduled on the same day as AgileDC next year, I plan to be there.  Now I just need to get my session ready to submit to PMI!

I want to thank everyone who attended my session, When PMI Introduced the Elephant in the Room.  I'll save details about my session for another blog post. Special thank you to Tonianne DeMaria Barry , co-author of Personal Kanban for attending my session.  Strange how you can "know" so many people from Twitter and never meet them in person.  I guess I just need to get out more.

My session was well received (no fruits or vegetables were thrown) and I received some really positive feedback.  The common note was "Wanted to hear more about the PMI-ACP".

I even convinced Richard Chang of Excella to wear a muscle suit!  In appreciation to him putting him self out there and being an Agile Leader, I won't publish the photos of him.  What happened at AgileDC will stay at AgileDC.

PMI-ACP Learning is Fun

This week I debuted my PMI-ACP class to the Washington DC/Baltimore area.  Being this was the first time I was offering this class, I had a little trepidation.  Would my students take to my teaching methods?  As I walked into the training center, I passed another classroom.  It was a 5-day PMP exam prep class.  It was a 5-day PMP exam boot camp. Knowing how boot camps are presented, I knew I did not want the same for my class. I was looking to do more that teach people how to pass a test.  I really wanted them to walk away with an understanding of concepts like self-organization, adaptive planning, continuous improvement, or delivering value.  I was looking to spend a lot less time lecturing and a lot more time engaging my students with discussions, simulations, and games.

Over the course of the next three days, we held lengthy discussions on real-world topics.  I would introduce a concept and ask questions like now that I've talked about Concept A, how could you apply it at your organization?  The class would then compare and contrast different scenarios from each of their respective perspectives.  But, I have to admit, some of the best moments of the class came when we played games.  Activities ranged from building paper airplanes, to playing the "ball point" game and building a town out of Lego's.  I can't express the satisfaction I got, when I saw "lightbulb" moments for each of the students.

One of the attendees just wrote me an email, saying:

The class was excellent!  This has been the most valuable class I have had relative to understanding Agile and applying it to my organization.

We had 6 early-adopters at the first class and I got some excellent feedback.  I know the next class will be even better.  Anyone have some Lego's for sale?

When PMI Introduced the Elephant – Part 3

This post concludes my 3 part series about when PMI Introduced the Elephant in the Room.  It's the basis of my talk at AgileDC on October 26. The elephant I am referring to is the mainstream adoption of Agile.  In part one of my series, I introduced the idea that Agile was about to cross the chasm.  The chasm I'm referring to is based on the "Technology Life Cycle Adoption Curve" concept from Geoffrey Moore's 1992 book Crossing the Chasm. I see parallels between a technology life cycle adoption curve and a methodology life cycle adoption curve.  Though waterfall may be at the far right, with the laggards and skeptics, I see Agile as being embraced by the innovators and visionaries for the last 10 years.  But within the last view years, the earliest adopters and visionaries started to get traction.  It took real leadership to follow a few "lone nuts" and brave ridicule. There comes a time within the adoption curve that the tipping point occurs.   If the original Agile leaders were the flint, the first followers were the spark that made the fire.  With PMI creating the PMI-ACP certification, there is going to be a lot of fuel on the fire.  After teaching my first PMI-ACP class over the last few days, I asked my students why they were pursuing this certification.  What made it different?  Their answers were both enlightening and similar.  The common answer was that their organizations see the PMI endorsement of Agile methods as the legitimizing of Agile.  Until PMI got involved, Agile practices were "undisciplined ideas from those on the fringe".  Even with the certification being in the pilot stage, it has rapidly become a viable alternative to other processes that just aren't working.  Though Agile isn't for everyone, I find it amazing that so many have not adopted it, merely because it wasn't supported by the status quo.

I'm actually not sure where we are on the adoption curve.  But, from listening to my students, the fear of ridicule is being stripped away.  I do believe we are crossing the chasm.

Watch this 3 minute video.  If you are a version of the shirtless (Agile) dancing guy at your organization, all alone, remember the importance of nurturing your first few followers as equals, making everything clearly about the movement, not you.

Be public. Be easy to follow!

There is no movement without the first follower.

(Link to Video on YouTube)

When PMI Introduced the Elephant - Part 2

In just a few weeks, I will be speaking at an upcoming (sold out) Agile conference here in Washington D.C.  It's unfortunate that I had to decide between going to the PMI North American Congress and speaking at the AgileDC event.  The events are happening the same week.  I had to decide if I wanted to speak or if I wanted to just attend. The title of my talk at AgileDC is "When PMI introduced the elephant in the room".  Let's define that.  We're talking about an important and obvious topic, which everyone present is aware of, but which isn't discussed, as such discussion is considered to be uncomfortable.  That elephant, of course, is the mainstream adoption of Agile.  Many of us saw the momentum of agile practices growing.  And I think just as many out there have tried to ignore it, misrepresent it, or dismiss it.  Though it took 10 years, I see PMI's move to formally embrace Agile, with its own Agile certification, as a sign we're about to cross the chasm.  The PMI wouldn't do this if they didn't see market trends supporting it.  With the PMI endorsement, Agile will be more widely used, more openly adopted...and yes, abused.

But I'm not here to rain on PMI's parade.  I take my hat off to the PMI leadership, the PMI Agile Community of Practice leadership, and the informal Agile luminaries we all know in the industry.  I know there are people who are not very happy with the idea of PMI being the organization to release a comprehensive Agile exam.  Like it not, someone has to do it!  Agile needs something that will motivate people to accept it as a legitimate alternative (or primary choice) and leverage it.  Though not every project environment appears to be conducive to what the Agile Alliance or the Scrum Alliance offer, they seem to be more receptive when the PMI offers it.  In the U.S. market, the Project Management Professional (PMP) certification has reached a point in the adoption curve whereby if you are a Project Manager and don't have it, you are at a disadvantage.  It has reached such a fever pitch that even people who are not Project Managers (by trade) are finding ways to get the certification.  People are believing certifications will make them more marketable and better managers or leaders.  PMI is merely capitalizing on that belief, with the introduction of the Agile Certified Practitioner certification.  A certification that is not easy to get, immediately has a perception of value.

When you think of PMI, what do you think of?

Processes and tools?
Comprehensive documentation?
Contract negotiation?
Following a plan?

PMI is the world's largest project management member association, representing more than half a million practitioners in more than 185 countries. As a global thought leader and knowledge resource, PMI advances the profession through its global standards and credentials, collaborative chapters and virtual communities and academic research.

When you think of Agile, what do you think of?

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

The authors of the Agile Manifesto wrote "We are uncovering better ways of developing software by doing it and helping others do it."

So, is this a contradiction?

When PMI Introduced the Elephant - Part 1

Last October I entered the Gaylord National with a little trepidation.  The PMI North American Congress was taking place and I found out that several people I admire in the Agile space were going to be attending and speaking.  Leading up to the major PMI event, I was hearing a lot of chatter about these "heretics" who were going to be presenting.  In Washington DC, the PMP was king and few in the Federal space wanted to hear anything about adaptive planning, continuous elaboration, or focusing on delivering value to the customer.  Project Managers were expected to predict the future, define process and then make damn sure you followed it, regardless if anything ever got delivered.  So, I was very much surprised as I walked through the Gaylord and noticed poster after poster, display after display.  "Are you Agile?" Every Agile session I attended, PMI Vice President of Information Technology, Frank Schettini introduced the speaker and told the audience that he leads the team that is responsible for delivering value to PMI’s members, volunteer leaders, certification holders and staff through innovative and reliable technology solutions. He said that he was a strong supporter of the Agile Community and so was PMI.

Though the audience at one of the first Agile sessions was almost hostile towards the presenters, by the time Michele Sliger gave the final session on the final day, there was buzz in the halls of the Gaylord about how "this Agile thing" had taken the conference by storm.

While I was there at the conference, I was privately asked if I would be willing to assist PMI with the creation of an Agile certification.  I was very apprehensive, at first.  I didn’t want PMI "hijacking" Agile.  I was assured that was not the case.  I discovered those I respected most in the industry were already hard at work, making sure it was done right.

Agile was about to cross the chasm and PMI was going to make sure we made it to the other side.

But first, introductions were in order.

Looking for Lean in Inefficient Processes

This morning, I wrote a physical check and placed it into a physical envelope. I hand-wrote the addresses on the envelope and even put a physical stamp on it.  I will mail it, when I take my semiweekly trip to the mailbox.  This is the first time I can remember doing this in a few years.  The party recieving my payment is forcing me to follow this inefficient business process of mailing a physical payment to them.  All I can think is how this used to be the norm and now how ridiculously inefficient it appears. When objectively judging the efficiency of this process, I started by first measuring two things, the Work-in-Process (WIP) and the Average Completion Rate (ACR).

Little's Law

This law provides an equation for relating Lead Time, Work-in-Process (WIP) and Average Completion Rate (ACR) to any process. The law states: Lead Time = WIP (units) / ACR (units per time period).  The idea is to have the lowest lead time as possible.  Lower lead times means less waste.

Am I the only geek out there who does this?  Where do you see inefficient processes that could benefit from a more lean approach?

Write the same but different words

It's all in how you say it. Or, in the case of this video, how you write it. In less than 2 minutes, this video will send a powerful message. It's about writing from perspective. After watching it, I immediately thought of how a user story can communicate a message differently, compared to a standard "shall statement" requirement.

Here are as few formats for you to compare. Which would you use?

As a <role>, I want <goal>

As a <role>, I want <goal> so <reason>

Given <dependency/constraint>, as a <role>, I want <goal> so <reason>

Do you have a preferred user story format that you use?  Please include it as a comment and have a beautiful day.