Enterprise Governance for Agile (02 July 2014)

In the world of Scaling Agile to the Enterprise level, the gap we have always dealt with in optimizing PMOs is once again showing up in Agile settings.  During almost every meeting with customers this past spring and summer it has become clear that this massive gap between Agile Teams and organizational leadership exists in almost every situation.  For the past two decades we have pictured this gap using VSPT:

Graphic 6 - VSPT

The line between Strategy and People is there to help demonstrate that there is a disconnect between People & Tasks and Vision & Strategy.  Every time we have used this graphic in training or consulting situations, we get universal agreement that the gap is real, significant and exists in their organizations. It comes as no surprise that Scrum and Agile, as a framework or methodology, does not address or cure this disconnect.  Yes, the values in the Agile Manifesto may (or may not) scale to an organization, but the Manifesto limits itself, by definition, to only software development and focuses on improving team level performance.

The gap occurs, in large part, because different language is used at the executive level.  We try to show this with our image below:

Languages of Leadership and Management

There are tools and methods aimed at how to bridge or mitigate specific parts of this gap (i.e. SAFe, Management 3.0, Enterprise Scrum, DAD, etc.).  But, the only framework that we are aware of that successfully addresses Enterprise-level governance issues is the Unified Vision Framework.

At Nature Publishing Group (NPG), when I (Andrew) was there leading the Waterfall to Agile transformation, part of the equation included putting in place an Agile PMO (Program & Portfolio Management Office).  But, we quickly learned at NPG that an Agile PMO wasn’t enough to complete the transformation.  We found that we also needed an Agile Transformation Group (ATG) to help champion the massive changes we were implementing throughout the organization.

The ATG consisted of senior executives.  It included Technology’s Portfolio Manager (Andrew), the Head of Platforms, the Head of Development, the Head of Product Management, the Head of Project Management (including the two senior managers in charge of all of the ScrumMasters/Project Managers), and the Head of the Developers.  Some of the key items that the ATG delivered were:

  • The agreed upon definition for “NPG Agile”
  • Sorting all of the development teams into persistent (dedicated) teams
  • Handling of exceptions
  • Communication with the Board and C-level
  • Normalizing Agile between the various offices and countries involved

The above list can look deceptively simple.  Getting those items done in an organization that had a legacy command-and-control culture took the ATG over 1.5 years to complete.

At the same time, the PMO delivered the following key items:

  • Training 250 team members and stakeholders in “NPG Agile” during a 12-month period
  • Facilitated the forced-prioritization of the 250 projects in the pipeline at initiation of the transformation, reducing the list to 100 projects
  • The baseline of project completion performance was 60 project per year in 2011
  • By 2013 the newly trained “NPG Agile” teams were able to deliver 124 projects per year, more that doubling the productivity without adding additional resources
  • Increased Communication, Reporting and Transparency with the ATG, Board and C-level

The PMO also handled standards, templates, etc.  But, for example, we eliminated the use of a full-blown business case for all projects.  Just the “template” for the Business Case was 12 pages long and once filled-in could be as much as 50 pages.  So, for over 80% of all projects we substituted in a one-page business case from which the executives could make quick decisions.  This is one reason for the increased throughput.

Both the PMO and ATG members were also actively involved in the budgetary process, but we found that once we dedicated the teams they became a fixed cost.  As a publisher, we were also dealing with fixed deadlines in most cases as well, so the variable became scope.  When it became clear (via our reporting structure) that a team was not going to be able to deliver the minimum viable product by the due date, then the executives were, once again, forced to prioritize (or re-groom the project backlog).

This early warning radar worked really well for the executives.  For example, one time we had a Product Manager (and the Product Owner reporting to her) that kept communicating to the ATG and the Board that a key project would be delivered in April.  The team kept reporting back to the PMO that this wasn’t the case.  Once we pinpointed the cause of the disagreement, it was clear that the Product Owner had miscalculated time allocated to the project by a factor of two.  Their estimates and reports were corrected and the PMO communicated the new delivery date of July/August back to the ATG, Board and C-level.  Once they got over the initial shock, they realized that they had just been warned of a problem 4 to 5 months earlier than they would have using the old system.

So, we have found that an ATG plus an Agile PMO are superb tools for Scaling and Governing Agile at the Enterprise level.

But, what about companies that have started out Agile right from the beginning or that consider themselves fully transformed to Agile?  Do they need an ATG and an Agile PMO?

In those cases, they will need both an AGG (Agile Governance Group) and an Agile PMO that will help them continue to mature and fully scale Agile to the Enterprise level.  An AGG will have all of the same functions as we described for the ATG in the example above:

  • The agreed upon definition for “Agile” for the organization
  • Sorting all of the development teams into persistent (dedicated) teams
  • Handling of exceptions
  • Communication with the Board and C-level
  • Normalizing Agile between the various offices and countries involved

Of course, this assumes that the organization’s Program and Portfolio management have already moved into an Agile way of working.  If not, then there is quite a bit of work to do on two fronts, instead of one.

By the way, Scrum of Scrums (SoS) isn’t a viable substitute for Agile Governance.  At best, it is a tool that can synchronize a number of teams that are working on the same product/project/effort.  Some organizations have found the SoS to be helpful at the project/program level for this very purpose.

There are other more powerful tools, like the walkabout workshop, that can be used at the program and portfolio levels to help capture and create transparency for the cross-dependencies and integration items that extend outside of a multi-team project (i.e. items that cut across multiple tribes, programs and portfolios).

Also, entrepreneurial companies that have started out Agile will find that somewhere around the 700 to 1,000 person range that the abilities of the organization to organically manage itself will be outstripped by its growth.  It’s at this point in time that “Team Agile” stops working and the need for “Business Agile” kicks in:

Governing Team thru Business Agile

One significant mistake that many companies are making is trying to use agile coaching methodologies to scale agile to the enterprise level.  To be fair, some agile coaches may have the skill, experience and ability to assist organization at this level.  However, we have observed that most agile coaches can’t scale.

We will address why agile coaches can’t scale, and probably shouldn’t, in our next blog post.

Advertisements
1 comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: