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.