Agile PMOs and COEs

I have been conversing with a colleague recently about Agile PMOs[1] and COEs[2]. For those of you who voraciously read all my posts (I may be the only one) allow me to share my thinking.

I tend to agree with managedagile.com[3] as to the basic functions of an Agile PMO which, by inspection, are markedly different from a traditional PMO:

Agile PMO functions on behalf of the development and delivery organization: 

  • process/progress monitoring
  • process guidance
  • process support
  • liaison from the overall IT organization to teams, via their Scrum Masters

We note that PMO members are typically a separate small team. For me, their value at this level of operation isn’t clear, as expressed by scrum.org[4]. If they are, in addition, the Scrum Master Chapter or Guild (to use the Spotify parlance[5]) then they are adding a bit more value to the organization. If they’re pretty focused on measurements and feedback, then they add even more value. That makes them pretty close to an Agile COE, but without significant support for Agile adoption. These days, I find adoption support to be crucial for most organizations, so the COE is a better model than the PMO and supports most, if not all, the PMO’s functions:

COE functions:  in addition to the above

  • communicating – no, let’s instead say socializing, the business need, urgency, vision, strategy, and roadmap for change (i.e. organization-wide adoption of Agile) – these are the artifacts driving change
  • developing the implementation plan for transformation to Agile, managing the transformation backlog, and managing dashboards regarding it to make progress visible
  • establishing a measurement plan, with metrics, and facilitating the execution of that plan
  • developing and executing a training plan to train personnel in Agile methodologies, e.g. Product Manager, Scrum Master, team member, etc., also continuing education
  • identifying value streams and products around which to base teams and teams-of-teams
  • fostering appropriate communities of practice (Spotify model might say guilds and chapters)
  • maintaining a highly visible presence, probably somewhere well known on the internal intranet – the one-stop-shopping concept
  • maintaining a cadre of good mentors, coaches, consultants to assist wherever needed
  • fostering a relentless improvement attitude with innovation at its root

Some of the COE members typically comprise a separate small team, but their membership also includes many people who might not be considered part of the team – the guiding coalition who developed the artifacts driving change, the steering committee driving the change day-to-day, the mentors/coaches/consultants who are on the ground making it happen for the organization.

To sum up, Mindtree[6] says it’s all about culture, community, innovation and expertise. Some say that a COE should NOT be monitoring; your choice, depends on the organization. Finally, here is a SAFe® specific version of the COE, or LACE[7], that I’ve found helpful also.

 

[1]Program Management Office or Project Management Office – one is never sure!

[2]Center of Excellence, an ambiguous phrase if I ever saw one

[3]http://managedagile.com/what-is-an-agile-pmo/

[4]https://www.scrum.org/resources/blog/agile-pmo

[5]https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ – by the way, I think Spotify is a really good and visible example that can be used to show an IT department that their value to the company is significant and that IT should never be thought of as a cost center.)

[6]https://www.mindtree.com/about/investors/annual-reports/annual-report-2015-2016/cultivating-future/agile-center-excellence

[7]https://www.scaledagileframework.com/LACE/

Leave a Reply