The Agile PMO

Tackling the PMI-ACP Certification Exam

By now I am guessing that most people have heard of the Agile Certified Practitioner, or PMI-ACP, the newest certification program from PMI.  I was excited when I first learned of it because I have been very interested in agile methods and projects.  Plus, frankly I like the idea of getting another credential which will help set me apart, especially in an area that is exciting and growing like agile.

Why did PMI create the certification?  As a professional organization, they have a good track record with providing rigor around PM certification.  They are credible and probably the best positioned to bring some standardization to what is now a relative young and inconsistent field.  Prior to this there was not a single best agile certification.  The most popular previous certification was probably the certified scrum master (CSM) and that is: 1) unique to scrum and 2) so easy to achieve to be almost meaningless in the industry.

Obviously another reason that PMI created the new PMI-ACP certification is to capitalize on the growth and popularity of agile.  It would be hard for PMI to continue to ignore agile methods given the growth of agile and the increasing percieved divide between those agile methods and the PMBOK® Guide.  As PMI noted on their website:

"The use of agile as an approach to managing projects has been increasing dramatically over the last several years. Gartner predicts that by the end of 2012, agile development methods will be used on 80% of all software development projects. PMI’s research has shown that the use of agile has tripled from December 2008 to May 2011. Furthermore, research demonstrates the value that agile can have in decreasing product defects, improving team productivity, and increasing delivery of business value. The PMI-ACP is positioned to recognize and validate knowledge of this important approach."

And there has been a perceived divide between agile and the PMBOK® Guide.  Many agile enthusiasts would say that agile is the opposite of all things PMI: project managers, PMOs, and most of all, the PMBOK® Guide.  PMI addresses this perception directly and points out that there is no true conflict between agile methods and the PMBOK® Guide:

"The PMBOK® Guide—Fourth Edition contains principles of project management and project management processes. These processes describe "what should be done during the management of a project." Agile methodologies are different in that they describe "how to do the things that should be done" – in short, “what” versus “how.”

A quick side note - the PMI certification spans all specific methodologies like XP, Scrum, FDD, TDD and others and focuses on the common principles across all of those. This is really important because if you have experience in just one aspect of agile, you will have a difficult time when it comes to the exam.

Requirements to Qualify for the PMI-ACP Exam

The PMI-ACP is similar to the PMP in requiring both experience and training to qualify to sit for the exam.  You need 2,000 hours of PM experience, 1,500 hours of agile experience, and 21 contact hours of agile related training (cannot be self study) to be eligible to sit for the exam.  If you are a PMP, you don't need to worry about the PM experience.  The agile experience can be more difficult to obtain.  You need  to show 1,500 hours working on agile project teams. These hours are in addition to the 2,000 hours required in general project management experience and they must be earned within the last 2 years.

Planning for the Certification Process

Assuming you have (or will have) the experience you need to take the exam, I would strongly recommend that you develop a preparation plan for completing the application and then preparing for and taking the exam.  Your plan should take into consideration the time you have available, your current level of experience with agile, and the breadth of your current understanding of agile.  As noted above, the exam covers a wide spectrum of topics and if you lack a broad understanding of agile, you will have to plan for more studying.  

I was pretty fortunate in that I had been exposed to agile in different projects and programs going back to 2003.  But what really helped me was developing and delivering a training course on agile project management in 2008, which was largely based on Jim Highsmith and Michele Sligers books.  I was also just recently part of the leadership for a large scale agile transformation, during which we had several training courses and brought in outside coaches and consultants.  My own reading on the topic helped to round up my understanding.

My own preparation plan was very aggressive.  I decided in mid-December that I wanted to get the certification and I thought I could do it in 30 days or less.  I had spent enough time on the PMI website to determine that I was eligible to sit for it and then I just went ahead and filled out the application on line which took about 90 minutes.  I did this before actually scheduling my exam (and paying the fee).  I received notification within a day that my application was accepted.

When I initially tried to schedule the exam for 30 days out, I could not.  The pilot exam closed on November 30 and the exam wasn't available again until the launch of the official PMI-ACP exam on January 31.  Initially I was bummed that I would not make the 30 day goal but I realized that the timing was perfect since I had some downtime between projects which I could devote to study.  I decided to study all the recommended books that I could and then use practice exam questions to help me pinpoint areas for further study.  I had not planned to take a preparation course.  I thought that if I studied enough for 3-4 weeks, I could take and pass the exam on January 31.

I also joined the PMI-ACP study group on LinkedIn, which was very helpful.  I went back and read all the discussion threads and there was some really good information there about the process and generally about the content, though nothing specific about the content.  The discussion group provided additional context for the exam topics which was helpful.  There were also comments from numerous people who had taken the pilot exam and were sharing their experience.  

Study Materials - The AgileBOK

OK, that was a joke, there is no AgileBOK or an agile equivalent of the PMBOK® Guide.  Heck just putting the words agile and PMBOK in the same sentence is considered offensive by many people, agile purists and PM purists alike!  Instead of a PMBOK® Guide equivalent, PMI has provided a set of 11 books that the exam materials are based on, a content guide, and an examination guide.  The 11 books are listed here, in the order that I found them most useful for the exam.  These are the books that I read pretty much cover to cover:

• Agile Project Management with Scrum, by Ken Schwaber
• Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, James R. Trott
• Agile Project Management: Creating Innovative Products – 2nd Edition by Jim Highsmith
• Agile Estimating and Planning, by Mike Cohn
• The Software Project Manager’s Bridge to Agility by Michele Sliger and Stacia Broderick
• The Art of Agile Development by James Shore

I did not read any of the following books, mainly due to time.  Cost was also a factor since buying all these books was beginning to add up!

• Agile Retrospectives: Making Good Teams Great by Esther Derby, Diana Larsen, Ken Schwaber
• Coaching Agile Teams by Lyssa Adkins
• Agile Software Development: The Cooperative Game – 2nd Edition by Alistair Cockburn
• Becoming Agile: ...in an imperfect world Greg Smith, Ahmed Sidky
• User Stories Applied: For Agile Software Development by Mike Cohn

Because I was working on agile PMOs, scaling agile, and enterprise agile adoption, I also read the following books.  They are excellent books though they are not on the recommended reading list or necessarily directly applicable to the PMI-ACP exam.

• Succeeding with Agile Software Development using Scrum by Mike Cohn
• Lean Software Development an Agile Toolkit by Mary and Tom Poppendieck
• Scaling Lean & Agile Development, Craig Larman and Bas Vodde
• Scaling Software Agility, Dean Leffingwell

I purposefully didn't seek out any "How to Pass the PMI-ACP Exam on Your First Try" books when I was preparing for the course.  I know that there are some PMI-ACP Prep books under development or now released.  I just didn't look for them because I was interested in reading the original authors rather than just getting partially digested material to help me pass the test.  

(UPDATE on Feb 20:  Mike Griffiths has written a PMI-ACP Exam Prep Book for RMC.  He provides some great background information about the content of the exam in the following blog post:  PMI-ACP Book Coverage on Leading Answers Blog.  I didn't use and cannot endorse the book, though I have long been a fan of Rita's PMP Exam prep materials.)

PMI provides a lot of information about the exam content including a breakdown of the % of various questions between Tools and Knowledge, and between 6 domains.  I looked this over but frankly found it confusing and not helpful to me.  See the link for the Exam Content Outline below if you think this will be helpful to you.

Preparing for the exam

I was doing a pretty good job of working through the books in those first few weeks of January.  I kept checking on when I could take the exam and the first available date was January 31.  On January 23rd, I learned of an opportunity to take a 3-day PMI-ACP preparation course from Agile Transformation.  This wasn't part of my original plan since I had the 21 contact hours of agile training from my previous assignment.  But since I was within 8 days of my test date, I decided to take the training and I am really glad that I did. 

I don't know for sure if I would have passed the test without it.  But I know that the course helped to round out my knowledge of the topics and to boost my confidence.  I also found the framework for the class materials very helpful and something I hadn't experienced prior to that time.  I also had a chance to meet Sally Elatta, who is a dynamic and energizing speaker and instructor.  (Disclosure:  I am now partnering with Sally Elatta and Agile Transformations to provide training courses and consulting services!)

There is one other very important benefit to taking the training course from Agile Transformation.  I realized within the first day that I knew more than I thought and I was probably ready to take the exam.  I think that without having the training, I would have underestimated my agile knowledge and spent much more time and energy in preparing and that would have been wasted time and effort.  This would violate a key agile principle:

"Simplicity - or the art of maximizing work not done - is essential."

Don't study more than you need to - the test is pass or fail.  By the way, if you don't have the 21 contact hours of training, I definitely recommend a PMI-ACP exam preparation course and I certainly recommend the course from Agile Transformation!

Practice Exams

The course that I took included access to AgileExams.com for PMI-ACP practice exams.  They are probably not the only provider of these practice exams but I think they are the current industry leader.  The practice exams were helpful for getting a sense of the breadth of the test and the length of time it would take to complete the exam.  Over the next week, I took 3 full tests of 120 questions as well as several shorter practice exams. 

I wish I could say that agileexams.com were helpful in building my confidence - they definitely were not!  My scores on the practice exams ranged from 72% to 80% and they considered that failing.  (It's not clear what score is passing on the official exam - it isn't published and some of the 120 questions on the exam are draft questions that don't count toward your score). 

The main  reason that I did not score higher on the practice exams was related to the depth of coverage of some specific approaches from the books above.  As an example, there were several questions from the AgileExams that related to the specific phases of the Agile Project Lifecycle in Jim Highsmith's book (i.e. envision, speculate, explore, adapt, and close).  These phase names are unique to his book and not common across the industry and so (thankfully) were not included in the actual PMI exam that I took.  So I think the AgileExams are helpful in preparing for the exam.  And I think that over time they will get closer aligned to the actual exam.  At least for now I think you can assume their practice exams are harder than the real thing from PMI.

I should also mention that the preparation course I took from Agile Transformation also included some sample exam questions and these were much closer to the PMI exam question than those from AgileExams.  I saw some that were very similar to those on the actual exam and so in that respect, they were even more helpful than those from AgileExams.com. 

The Actual Exam

I read somewhere that if you are practicing agile, the exam will be pretty easy.  I agree.  Many of the questions turned out to be pretty straight forward based on my experience.  If you don't have broad experience,  you will also be challenged.

When taking the exam, I found that I was very confident about my answer on the first pass for about 100/120 questions.  If I wasn't sure, I marked them for review and then came back to them after getting to the end of the exam.  Upon review of the 20 I wasn't sure about, I was able to confidently answer another 6.  For the remaining 14 questions, I found that I either had no clue at all, or it was a coin toss between two possible answers.  That was a little un-nerving but I remembered that there were extra 'test' questions that were being included and would not be scored so I hoped the ones that I struggled with fell into that category.  For those questions that I had no clue on, I used some rather unscientific methods of picking an answer and for the others, I just chose something reasonable.

The exam took me just over 1 hour to complete.  That included a gut-wrenching 5 minutes when the PC I was using crashed on question 56 and I had to go get help.  Fortunately, the staff at Prometric was able to get me back to my question and nothing was lost. It was a little unnerving though.

I knew that I had passed right at the end of the exam.  I did not receive any diagnostic information about the questions that I missed and I would have liked to have received that. 

Useful Links

I have included below some of the links that I found helpful in preparing for the exam. 

• PMI-ACP Handbook:  http://www.pmi.org/en/Certification/~/media/PDF/Certifications/PMI-ACP_Handbook.ashx 
• PMI-ACP Exam Content Outline:  http://www.pmi.org/en/Certification/~/media/Files/PDF/Agile/PMI_Agile_Certification_Content_Outline.ashx 
• LinkedIn - PMI-ACP Certified Practitioner Exam Prep Study Group:  http://www.linkedin.com/groups/PMI-Agile-Certified-Practitioner-PMIACP-3809643?trk=myg_ugrp_ovr 
• AgileExams:  http://www.agileexams.com/
• Agile Transformation (my PMI-ACP training course provider):  http://agiletraining.com/
• Excellent Study Tips from Sally Elatta:  http://agiletraining.com/2011/09/24/pmi-acp-agile-certification-exam-study-tips/#

 Good Luck and I hope this information is helpful!

Anthony

No thank you, Agile just doesn't work for us

 I recently attended a PMI Chapter meeting and chatted up as many PMO leaders as I could about adopting agile methods.  I was surprised to hear from more than one of these leaders that "agile just doesn't work for us".  Here are some of the comments that they made about their agile experience:

We tried it on one project and it failed miserably. Now our CTO says we are not allowed to use the word agile to describe what we are doing.

We had a bad experience and we believe that agile is just not a fit for us.

Huh? I found this a little surprising since Gartner predicts that 80% of all software projects will be moving to Agile methods within the next few years. It seemed to me that the PMO leaders are either 1) part of the 20%, 2) not in a software or IT related industry or 3) a little out of touch.

Of course, upon hearing their initial comments I quickly shifted into Columbo mode and had "just one more question" for them. It turns out, in both cases, the agile adoption was driven organically from the bottom up. Both projects didn't have a defined end, they just kept lingering on.  And in both cases, they lacked a dedicated product owner. Actually, in the first case they had a product owner but the business went around the product owners and communicated directly with the developers about what they needed.  Yikes!

When I asked about what the second project was doing that was agile, it seemed that what they were doing was whatever people wanted or perhaps were always doing, and then calling it agile. 

I think the lesson for me is that PMOs have many concerns and agile adoption is not high  on their list of priorities (yet).  They haven't taken the time to learn about agile and support their fledgling agile efforts.  I also think that another factor is that change is difficult, and PMOs simply aren't the most 'change friendly' organizations.  

One thing that is certain - the PMO and agile enthusiasts are on a collision course.  Traditional PMOs are going to need to understand and in most cases embrace agile methods in order to demonstrate business value to their organizations, and to help their organizations be more competitive.

Your thoughts?

Anthony

What is the role in Agile for Project Managers, Program Managers, and the PMO (part 2)?

This is a follow up to my previous posts about role changes for project managers and program managers working in an agile environment.  My last post talked about project managers and in this post, I am going to focus on the program management role.  We might have to tackle this over a couple of different posts!

First, let's start with the role and defined activities for the program manager.  In the PMI Standard for Program Management, the program manager role is described as:

1. Supporting and guiding the individual project managers, in particular to help them understand how their work fits in the big picture
2. Achieving the program and organizational objectives
3. Structuring the program and related processes to support the teams to complete their work and to integrate their deliverables to achieve the program end goal, product or service
4. Ensure projects are organized and executed in a consistent/standard way

Each of these activities plays out in an interesting way when program managers begin to incorporate agile teams within their programs.  This is exactly the thing that I have been challenged with over the last 10 years.

I had my first real experience with Agile back in 2003.  I was asked to lead the IT portion of a large program charged with large-scale data collection in the country of Qatar.  We had a number of teams working together to develop data collection tools and instruments.  Only one team was using agile methods (scrum primarily).  A highlevel project schedule is shown below with the agile activities called out.

 

At the time, we didn't think of this team as being anything different.  We created traditional plans based on a form of waterfall and ignored the fact that they were doing daily standups, they were self-organized, and that they pulled prioritized features and defects from a central backlog.

My next experience with the collision of agile and the program was in 2008.  I was working with an organization that was piloting and preparing to roll-out a vendor software product within their network of hospitals.  The product was an existing off-the-shelf software and the vendor was adding significant new features based on the feedback from our pilots.  A high-level timeline for this work is shown below.

The challenges with this particular product were mostly around the prioritization (and payment for) the added features.  Our pilot teams were providing feedback in the form of specific requirements that the vendor needed to deliver.  Though not written in user story format, the 100 or so statements of functionality were the features that the teams needed. 

Unfortunately the vendor wasn't very clear about how these features would be built.  We worked through an account rep and sometimes interacted with an internal product manager.  They considered our list, and our 'must have' features.  But they had an internal roadmap, that wasn't shared with us, that they used to drive their development.  This lack of clarity and expectations was a major risk for the program since we could not be sure of the functionality that we would get and we needed that to plan the rollout. 

It's also important to note that agile was appropriate for the development of the product.  However, we still needed to have traditional plans for training, rollout, technical support and other functions. 

Also in 2008, I led another large program.  This effort was actually a program within a larger program to support the launch of a global web platform.  There were 4 main components:  a program to develop the web platform (external to our program), development of an administrative system, development of back office application interfaces, and integration testing of the three efforts.  This is shown on the high level timeline below.

One of the challenges in this environment was the synchronization of schedules for the various teams.  For the back office integration teams, this development was done in a traditional way and was mostly completed.  For the platform and the administration systems, the development was being done using agile methods.  Unfortunately these two teams were not synchronized on their sprint cadence or their release points.  This caused numerous headaches for the integration test team who could not be sure what functionality would be delivered at what time.  We also ran into challenges with the development backlog, or more specifically the prioritiztion of development for items on the backlog. 

The last significant example of agile in the program environment occured in 2011.  I had joined a large business re-engineering program with multiple teams.  All the work was being done in a traditional waterfall manner and in fact, months had been spent trying to lock down requirements.  When a new program leader was brought on, he drove the transition of this program to adopt agile methods.  Within 6 months, we had moved to 10 scrum teams who were working from a single prioritized backlog and were delivering against one high level roadmap (see below).

With 10 agile teams, this became the standard method for organizing and driving the program.  There were 4 other teams that were operating in traditional methods but that became secondary to the scrum teams. 

The main challenge in this fourth example were that the Roadmap became the main driver for the overall program.  This replaced the function of the project schedules that were developed for other programs.  There were necessary points of communication and integration with all the teams - including the traditional teams - and these integration points became the main focus for program management.  Finally, it was critical that the program manager become versed in agile and champion the agile practices.

Some of the consistent challenges or takeaways across all 4 of these programs includes:

1. The greater the proportion of agile to traditional, the more important it is that the Pgm Manager embrace, champion, and enforce the use. 
2. Program Manager must be well versed in agile and champion agile practices.  Program managers should understand and leverage the flexibility that Agile teams can provide. Conversely, Methods like scrum actually require a lot of disclipine and the Pgm need to be aware of that.
3. Program Manager needs to understand the critical dependencies between teams and between the development backlogs.  Program needs to align team efforts around the roadmaps and release schedules for the agile teams.  Where possible, all teams should be on the same or a related cadence to simplify communications, training, UAT, and other downstream efforts.
4. It is critical to understand who is going to prioritize the items on the development backlog.  The program manager should be involved in decisions that affect the bigger picture and the other teams in the program to avoid sub-optimization.  A related issue is managing internal customer expectations is critical – feature priority and timing!

It seems inevitable to me that Program Managers are going to need to be comfortable incorporating agile methods.  Hopefully this post will help them thinking about what is required.

As always, I'd love to hear your thoughts.

Anthony

What is the role in Agile for Project Managers, Program Managers, and the PMO (part 1)?

If you are a scrum master or product owner, your role in an agile organization is pretty clear. If you are not sure about your role, you can pick up any agile book or ask Google and you will quickly get a clear picture. Unfortunately, there is little role definition for other traditional project and program management functions in the agile organization. This post, along with others to follow, will begin to explore the roles of project and program managers and PMO members in an agile environment.

The following diagram is my attempt to understand the landscape a little better. I've plotted level of change in the role (in an agile organization) against the level of definition provided for the new role.

As noted, the scrum master and the product manager roles are pretty well defined. And they haven't changed all that much.

The senior management role hasn't changed much in the agile enterprise either. In "Scaling Software Agility: Best Practices for Large Enterprises", author Dean Leffingwell identifies two related roles of senior management which I think sums it up pretty well:

1. Demonstrate dedication and commitment to the process
2. Lead by example

This shouldn't imply that the role is either easy or insignificant. Leading through any type of organizational change is critical and the senior management needs to walk the talk.

That leaves the group of 4 project and program management roles. These are roles that are largely undefined in agile and that will experience medium to high levels of change. The exact level of change in the role depends on several factors including the type of organization (Internal IT, SW Product, or other), the level of agile adoption planned or underway, and the existing role definition.

Let's look at each of these 4 roles and see if we can identify the key changes for each. I will tackle the project manager role in this post and the other 3 in my next.

The Project Manager

The role of the project manager is probably one of the most hotly debated ones in the agile community. Most agile purists believe that project managers are no longer needed or don't exist in agile team environments. I heard a speaker recently say that once agile is implemented, the project managers can become either a scrum master, a product owner, or find another position. That seems to be the prevailing thoughts about agile and project managers. In a previous post, I quoted agile enthusiast Tobias Mayer who blogged:

"...There may be such a thing as “Agile Project Management”. I don’t know, and don’t really care. It is of no interest to me."

Similarly, I was quite surprised in the first scrum master training course that I took when the instructor said that project managers could not be scrum masters. He referred to the PMs as the voice of management, while the scrum master is the voice of the team. This training and his opinions are reflective of the trend by agilists to be anti-management. It makes no sense to me! How can someone be for the team but against management at the same time?

Jim Highsmith, co-author of the Agile Manifesto, refers to this type of black and white thinking as a Dilbert view of the world where employees are the downtrodden and management are the trodders. I am pretty sure Jim thinks that there is a role for agile project managers since he wrote the book "Agile Project Management", now in it's second edition. Some of the key role changes that Jim speaks to for project leaders include:

• focusing on leadership-collaboration
• championing the vision
• putting more emphasis on staff selection, development, and encouragement
• creating an environment of high-trust
• mentoring
• moderating

Note that it is a little sad that this list implies that only PMs in agile environments need to think about these leadership behaviors!

Something that has become increasingly obvious to me in the last year is that one reason for the perceived lack of need for project managers is that we are often comparing apples to oranges. Many agile teams are highly focused on software development, often on a product that is sold in the marketplace. While project management may apply, the type of work these teams do is more like product management or a production activity. Applying project management techniques are likely to be the wrong tool.

There is also a tendency to think only of the agile software development activities and ignore all the related activities that projects or programs would address. This includes work before the development begins (business cases, prioritization and approval) and those that happen after development (customer training, customer support, product maintenance). The agile team can be highly productive by thinking only about the agile sw development activities, however, in most cases someone needs to think about and plan for those other related activities.

So that part of the PM role doesn't and won't change. Working with those external stakeholders like the customer and support teams, executives, and others is required for coordination and managing expectations. Like always, the PM is going to need to deal with schedules, reports, and plans.

As PMI continues to actively embrace agile methods, I expect that PMI will begin to refine the role of the project manager for agile organizations. The first foray into this is the PMI Agile Certified Practitioner (ACP) Certification. There is also work underway to create a SW Development extension to the PMBOK.

In my next post, I will look at the roles of the program manager, the PMO, and the portfolio manager. As always, I welcome your comments.

Anthony

 

Cage Match - Agile Purists vs. PMI!

This battle of agile vs. project management has many dimensions and has taken on epic proportions. On the extreme end of the agile scale are agile purists who believe that the fully functional scrum team is all that is required to deliver great products to customers. Project managers are to blame for years of unnecessary rules and processes that slowed down progress or resulted in failed projects. To hear them tell it, project managers and all things related to them (program managers, the PMO) should be eliminated or better yet, publicly flogged then executed.

On the extreme end of the PM scale is the PMI. With a focus on standards and processes as those outlined in the the project management body of knowledge (PMBOK) and a certification based on passing an exam, the PMI represents to agilists that which is most wrong about project management. Right or wrong, PMI is often seen to represent that which is most wrong about project management. (Agilists have even started a whisper campaign that PMI invented waterfall development but I think it has been proven that it was the Soviet Union that invented it in the 1970s to undermine the US.)

The battle has come to a head in the last year. After many years of ignoring agile methods, PMI has co-opted the agile camp by expanding the PMI brand to include management of agile teams and projects. In late 2011 they launched a certification for agile project managers (a term likely to irk agilists) which is on par with the established PMP certification. I am including a couple of posts below related to this move by the PMI. The first is from Tobias Mayer who writes blog under the banner of "Agile Anarchy". I think he represents the extremist argument pretty well. (Note that I have included the entire post so as not to appear to be taking words out of context).

Scrum is not Project Management

Scrum, and the way of thinking that it attempts to socialize in the world of work, has nothing to do with project management. Anyone who is laboring under the misapprehension that Scrum is some form of “Agile Project Management” is seriously missing the point. There may be such a thing as “Agile Project Management”. I don’t know, and don’t really care. It is of no interest to me. My concern is with changing the way people think and act, not with force-fitting old ways of thinking into a new paradigm that cannot accomodate it. The result we are seeing is a half-baked compromise.

Organizations like PMI, Scrum Alliance, ICAgile and others who are trying to grab a slice of the Agile market are like parasites feeding off the souls of people who really care about change in the world. It is a tragic mess, made worse by those so-called Agilists who justify the behaviour, and even buy into it. Old habits die so very, very hard. I am not interested in half-measures, or “corporate-approved Agile”. This strikes me as worse than useless. At least the previous command and control culture was honest. This fake-Agile is deeply disingenuous, pandering as it does to those in fear of real change.

I urge anyone who really cares about the future of business, and the health of human beings in the workplace to steer well clear of all these oblique, money-making, compliance-seeking efforts to tone down Agile and make it palatable to those driven to maintain the status quo. Seek something more noble. Please.

Tobias Mayer, Posted on: Monday, April 25, 2011

 A more moderate position is outlined in the post below from Ken Schwaber, co-founder of scrum and one of the original signatories of the Agile Manifesto.

The Project Management Institute has recently made announcements about its program to incorporate agility into its project management program. I of course welcome this and look forward to PMI shifting from its previous approach to an agile approach. The test of this will be, of course, the success of the projects that adhere to its principles. In the past, the success (or yield) of their predictive approach has been less than 50% of projects (on time, on date, with the desired functionality.) Most agile methods have a much higher success rate, including the success in cancelling low return on investment projects early. We will watch and see if those that employ PMI’s agile approach enjoy such success, or at least an improvement on the 50% mark1,2,3.

PMI in the past has embraced the predictive, mechanistic approach to project management. This was first espoused by Frederick Taylor in “Principles of Scientific Management,” which was the basis of the Ford Model T assembly line. It is an approach for predictable, high volume, low cost manufacturing. Its benefits accrue from squeezing all of the unpredictability from the problem space through standardization and repetition. Perfect planning, training, and repeatability are the hallmarks. Plan and then do over and over again. The measurement of success is the yield rate, which is often very near 100%. Productivity is optimized through perfect processes, invariant workflow, and optimized use of resources (people or machines).

Agile processes, by way of contrast, work for development of complex products, where there is some repeatability but there is more new development than old. Products have to be devised anew each time as the requirements, the technologies, and the capabilities and creativity of the people change. In these situations, we’ve found that just-in-time planning, with frequent inspection and adaptation is required. Risks are managed and predictability created by limiting the time span between these planning events, and by ensuring the transparency of all artifacts. We have also found productivity, quality, and creativity is greatly enhanced if the people doing the work also plan their own work. They are not managed as resources, but as people that can do their best when they figure out how to do the work themselves. Self-organization and cross-functionality are vital to the success of these teams.

We have found that the role of the project manager is counterproductive in complex, creative work. The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems.

In Scrum, we have removed the project manager. The Product Owner, or customer, provides just-in-time planning by telling the development team what is needed, as often as every month. The development team manages itself, turning as much of what the product owner wants into usable product as possible. The result is high productivity, creativity, and engaged customers. We have replaced the project manager with the Scrum Master, who manages the process and helps the project and organization transition to agile practices.

How PMI bridges the profound difference in philosophy, thinking, leadership and management between its traditional predictive approach and the new agile empirical approach will be fascinating to watch. How it refashions the role of project manager will be an exercise in agility itself. I for one wish the people at PMI the best. They certainly need a better success rate than 50% to regain the trust of their customers.

Ken Schwaber, posted April 24, 2011

 I think the focus on agile vs. PM obscures the real issue or issues.  The real issue is working together to deliver effective solutions for our customers.   It is about being lean and competitive.  It is about growing as an organization and providing opportunities for growth and advancement for each person. 

It will be interesting to see what happens with this PMI-ACP certification.  What I have already seen is a scramble by a number of traditional agile organizations to jump into the market for exam preparation training.  One could argue that PMI has effectively co-opted them into becoming part of their family of Registered Education Providers.

The Accidental Agile PMO

The meaning of the term 'Accidental Project Manager' was immediately clear to me the first time I heard it even though no one explained it to me.  It implied to me someone who had become a PM quite accidentally, likely through being asked to do a job that required project management.  I don't recall where I heard it but apparently the term goes back to 1988 and both Bob Graham at the Wharton Business School and J. Davidson Frame at George Washington University.  The idea is that people fumble or stumble into the role of project manager without really understanding the role.  It is quite possible they might be doing project management without knowing it is project management.  Through a trial by fire process they get the job done, learn, and often develop tools and skills that are required for that job.  Or they fail in some spectacular way.  

Hindsight is 20 20, as they say.  

 

In 2011 I was the PMO lead for a large program and I became the Accidental Agile PMO.  We had a large team (over 130 resources) distributed worldwide and we went from traditional development to agile development in about 6 months.  Many of the traditional PMO functions that I had performed prior to the transition became unnecessary after the transition to agile.  Fortunately for me, I had a pretty good understanding of agile after developing and delivering a course on agile project management in 2008.  Unfortunately for me, I didn't fully appreciate the changes that agile would drive at the PMO level at the time.  As a result, I lost some time fumbling  and stumbling and  wondering if I was doing the right things.  

 

It turns out that some of the time I was doing the right things, and some of the time I wasn't.  Experience is a great teacher.  I've had the chance now to reflect on my experience and begin to read the materials available on scaling agile and the Agile PMO.  Some of the most obvious things that I have learned that would have been good to know up front include:

• Once you form the scrum teams, try to keep the teams stable and bring the work to the teams.
• Have a clear product vision via the inception deck (thanks Jim Hlavaty)
• Scrum teams are design/build/test and should focus on SW development, not be a bunch of business analysts creating non-value add deliverables
• The product owner is critical!
• Scaling agile is possible, though it is critical to have coordination of the leadership, scrum masters and product owners, a centralized backlog, and appropriate tools such as VersionOne or Rally.
• A product team composed of product owner, analyst, lead architect, scrum master and development lead is important to success.
• Most traditional PMO progress reports are not important in an agile program.  That doesn't mean that you stop doing them.
• No matter how agile you are, you will often have non-agile projects in the portfolio to deal with.
• Resource overallocation kills.  Where possible, push to get a person on one and only one team.

There is more of course and I am still learning.  Over the next few months I am going to be exploring these and many other topics in more detail with the intent of helping others others in PMO and leadership roles who might find themselves in a simlar position.  I hope you will join in learning especially if you have been in an Agile PMO or think you might become an Accidental Agile PMO soon.

Do More with Less - A How To Guide for the Agile PMO

One of the concepts that resonated with me during my agile training was the concept of maximizing work not done.  This is the tenth of 12 principles behind the Agile Manifesto.  In it's entirety, the principle reads as:

"Simplicity--the art of maximizing the amount of work not done--is essential."

It still strikes me as an excellent idea and goal that should be consistently strived toward.  It is especially relevant for those of us (all?) who are constantly challenged to "do more with less". We have more work to do, and we are working longer hours.  With today's technology, most of us are on all the time so we have the ability and often the need to do work during hours that used to be non-working time.  How many of us find ourselves checking emails when we are engaged in personal activities or with family?  (My wife tells me that checking email in bed is not an aphrodesiac!)  So this principle of maximizing work not done is helpful and could result in us reclaiming some of our personal time.

It is clear how this principle is applied at the agile team level.  We don't write elaborate requirements documents or spend time building functionality that will not be needed or used.  But how does this principle of maximizing work not done aplly to the Agile PMO?  What is the work that can be avoided?  Here are some of the most obvious ones (more to come):

#1 - Adopt Agile Portfolio Techniques

• Don't start projects that are not needed or not properly resourced.  This seems obvious but it is surprising to me how often this occurs.  I was recently on a large high-priority business program for an organization.  There was a crisis (isn't there always?) and 5 key resources were pulled from the program to work on a new crisis project.  This put both projects at risk.  There are other cases where people work on projects that are not approved (rogue projects) at the expense of approved and prioritized work.  This is sometimes just a lack of coordination, but it can also result from people going off on their own and working on what they want.  This makes it really hard to kill projects.
• Eliminate multi-tasking as much as possible.  Numerous productivity studies have shown that assigning one resource to many different projects is wasteful.  Most resources can be dedicated to one team.  This has an added benefit over time of building teams that work efficiently together.
• Related to the prior concept is to staff projects properly.  One of the largest sources of waste at the portfolio level are projects that are starved for resources.  How many times have you turned up for a project meeting only to have key personnel missing due to multi-tasking or reassignment.  This is a time and morale killer for everyone involved.  The fits and starts that projects go through while trying to get resources assigned or reallocated to them is wasteful.  A more agile approach is to keep the project team intact and bring the work in an organized (i.e. backlog) to the team. 
• Time spent re-organizing teams to work on projects.  This includes kicking off new teams and projects, forming and storming stages of team development.  Sanjiv Augustine of Lithe Speed and Sally Elatta of Agile Transformation have both spoken or written on this top

#2 - Cut Out the unnecessary PMO Overhead

• Most (OK, maybe not yours) PMOs require a number of forms and reports that once prepared, will never be read by anyone.  PMOs have gotten a bad rap as a hurdle or roadblock to progress.  Whether that label is deserved or not, the reality is that there is often bureaucracy and paperwork that is requested from teams that doesn't go anywhere or mean anything.  Check to make sure that every form and report has a purpose and keep asking the question why. Replace those status reports buried in email trails with information radiators that provide clear and transparent progress reporting.
• In a recent "Lean Project Management" presentation at the PMI Chicagoland chapter, speaker Philip Gisi suggested that if you are in doubt about the usage of a particular report, prepare it but don't distribute it as you normally would.  If no one asks about it, it is probably waste and no one would miss it if it disappeared.  I did this exact thing for a weekly program level status report and found that no one even blinked or asked about it after a month.  Since we had other means of reporting data, I quietly dropped the report.  When we needed to report to management, I begain to rely directly on reports about the backlog (burnups or user stories) or we demonstrated working code.  After a few months, we largely abandoned the concept of weekly reporting in favor of reports that came directly from our agile tool and did not have to be prepared separately.
• Preparing for program reviews or stage gate reviews can be un-necessary.  At a recent consulting client, the program-wide reviews held every other month were a killer for the team.  Key leaders would spend the 1 or 2 days prior to the review preparing and then 1-2 days in the review itself.  Most of the time in the meeting was spent posturing and spinning the information (the program was nearly a year late) and not really used to address key issues.  Each team reported status slightly differently and in some cases, they presented only to themselves.  It was a feel good exercise that really didn't accomplish anything. 
• Eliminate duplicate data entry.  Time reporting and status reporting are two easy examples of duplicate data entry.  

#3 - Adopt Lean/Agile Approaches wherever it can work for projects

• Don't create work in process.  Any type of inventory is consider waste in a Lean project.  This includes those large requirements documents, analysis documents, or other work that is potentially throwaway, or requires someone to read and digest as a separate step. 

#4 - Practice Continuous Improvement at the PMO Level

• Work to standardize and optimize the processes that are being used in the organization.  Continually work toward making the PMO itself leaner and meaner, rather than building more and more of a beauracracy. 

I am sure there are other ways that the PMO can maximize the work not done.  Your thoughts?

Anthony

 

ESI's Top 10 Trends in PM for 2012

Last week J LeRoy Ward of ESI posted ESI's view of the top 10 trends in project management for 2012. I don't know if this is a prediction, wishful thinking, or a forecast based on their pulse of the PM industry. In any case, it is an interesting list.

1. Program management will gain momentum, but resources remain in short supply
2. Collaboration software solutions will become an essential business tool for project teams
3. Learning transfer will become the new mantra, but with little structured application
4. Agile blends with waterfall for a new “hybrid” approach
5. Smarter project investments will require a stronger marriage between project management and business process management (BPM)
6. Internal certifications in corporations and federal agencies will eclipse the PMP®
7. More PMO heads will measure effectiveness on business results
8. Good project managers will buck unemployment trends
9. Client-centric project management will outpace the “triple constraint”
10. HR professionals will seek assessments to identify high-potential project managers

I am pretty sure that calling Item 4, the blending of agile and waterfall, as something new is a little inaccurate. People have been doing that for a while. It is something organizations will need to address in more savvy ways than they have in the past.

The one trend on the list that I believe is quite timely and will have the biggest impact on the agile PMO is the shift to focus on business results. This is actually long overdue.

 

7. More PMO heads will measure effectiveness on business results While introducing tools, using methodologies, mapping project management practices, sending project managers to training, and increasing the number of PMP®s in the organization are important metrics for a PMO head to collect and report on, they do not speak to the effectiveness of the PMO from a business perspective. To judge business effectiveness, PMO heads need to determine if their work has had a positive, quantifiable effect on the business in terms of troubled project reduction, lower project manager attrition, and faster time to market. In 2012 the practice of measuring the outputs, not the inputs, of project management will gain traction.
Source: ESI International, Top 10 PM Trends 2012

So what does this mean? This is right up the agile PMO alley so to speak. Agile is all about measuring progress based on code delivered. Done properly, the code is delivered in the order that the business has prioritized it. So, agile projects deliver working code in the order that the business wants it. If this isn't business value, I don't know what is.

When it comes to demonstrating business value, you can forget about those overly optimistic progress and stoplight reports, and continual updates to projects in the portfolio being delayed or getting into trouble and moving out their delivery dates. Stage gate reviews also add little or nothing in the way of business value and accurate Gantt charts do little to show where business value is being delivered. Give me a burn up chart like the one below that shows clear progress of user stories delivered (i.e., working code or business value). That's what the PMO leads should begin to understand and monitor.

You can read the entire Jan 5, 2012 article from ESI International here: Top 10 PM Trends 2012

Cheers!

Anthony

Welcome to the Agile PMO Blog!

The point of this blog is to help PMO leaders understand, evaluate, and adopt agile methods for the projects and organizations they support.

There is a bewildering amount of information about how to apply agile methods like Scrum, XP, TDD, or Lean to a team of 7 or 9 developers.  By comparison, there is very little about how PMOs can integrate and support agile development teams, or to apply agile methods at the program, portfolio, or PMO level.

The desire to understand and adopt agile is high.  While not without costs, agile development methods hold the promise of higher productivity, higher quality, and more predictability.   The Gartner group predicts that by 2012 “agile development methods will be utilized in 80% of all software development projects”.

The push to adopt agile has come largely from the technical community.  Executive management may also push for it, but more commonly organizational leaders don't understand enough or fear it so actively resist adoption.  This leaves the PMO as often caught in the middle between agile enthusiasts (aka extremists!) and senior management.  PMO leaders are challenged to develop effective decisions and strategies when it comes to Agile adoption.

At the same time, many PMOs are challenged to demonstrate how they deliver business value.  In some organizations, justification for the PMO is an annual debate.  This makes them an easy target for those in the organization who would like to skirt some of the important governance measures that the PMO has deployed.

I hope you find information that you are looking for.  If you don't, please comment below. 

Thanks,

Anthony