Why Should Agile Teams Care About GP2.7?

[Dear Readers, for the past several months, our good friend Pat O’Toole, CMMI expert and seasoned consultant, has been collaborating with us on a monthly series of CMMI-related posts, "Just the FAQs." Our goal with these posts is to provide answers to the most frequently asked questions about the CMMI, SCAMPI, engineering strategy and software process improvement. This month Jeff reveals why it critical to identify and involve the right stakeholders. Take it away, Jeff! ~ the CMMI Appraiser]

We’re an agile team and everything we do is “face-to-face.”  You might say we “specialize in collaboration.”  Why should we care about “GP2.7: Identify and Involve Relevant Stakeholders?”  It’s seems like defining a process for this doesn’t deliver any value.

I agree, you shouldn’t care about GP2.7. You should REALLY care about it!

The entire premise of “agile” is predicated on strong collaboration, transparency, and, most of all, being engaged.  So the real question is, why would you even THINK this wasn’t important?

Perhaps the words are getting in the way. The CMMI, rivaled only by a Piers Anthony novel for its esoteric lingo, may not say it in an “agile way,” but the authors meant pretty-much the same thing you do.  Another way to say it might be:

“We need engagement, and where the heck are they?”

Years ago, when I was a CIO of a software company, members of our development team came into my office complaining about team members not participating in important project events:

“He never comes to the meetings we put on his calendar!”

“She plays with her email during every design review!”

“The business customer never shows up!”

“The other developers don’t even LOOK at the code before a code review!”

That sounds horrible!  And we were using Scrum too.  THIS WASN’T SUPPOSED TO HAPPEN! 

Their complaints required some additional investigation.  So I asked them, “how big a problem is this?”  and “which meetings were worse than others?”

Crickets.

Don’t get me wrong, they thought it was a BIG problem, and it REALLY annoyed them, they just couldn’t tell me how big it was.  Or how small, or how much risk it introduced into the project.  Nothing.

Or as I like to call it, whining.  Wah wah wah!

By now my radar was starting to overheat.  “Wait, agile is all about engagement, but you’re saying people are not engaged?” Ouch.  My brain was hurting!

Agile teams are usually pretty good at engaging in “ceremonies” that are defined by Scrum (daily standups, sprint demos, sprint planning, etc), but are similar to traditional projects when it comes to engaging with the other  – no less important – events like design reviews, code reviews, testing, and other valuable, but not specifically “agile,” events.

Those of you who follow my blog know that I’ve been writing a lot about Agile Values, and that without them adopting “agile” is bound to end up being a frustrating experience.  This is because agile is really a set of values, not a method or set of techniques.  Agile techniques, like planning poker for instance, were designed in direct support of the values, not the other way around.  In other words, there should be direct traceability between agile values, agile methods and agile techniques. Holding daily-standups doesn’t make you “agile” unless your organization values failing-fast, transparency, and collaboration.  If they punish you for uncovering risks and issues every day, those daily standups will go the way of the buffalo right quick!

So, there I was, listening to my agile team members complaining about their own team … not being agile. Ugh. 

At the time I didn’t know much about GP2.7, in fact I had never even heard of it.  But I did know that in order to understand the risks of lack of engagement I needed information, so I decided to do something about it.   GP2.7 is, after all, all about risk.

A customer I had been working with had been playing around with an idea called “TeamScore” to keep track of stakeholder attendance for status meetings.  I thought that since “agile” is ALL about engagement, why not apply TeamScore to all events (as identified by the project’s defined process) and use it as a primary indicator of agile project health?  If engagement is a pre-requisite for agile projects, it seemed like understanding this data was a pre-requisite for running a successful agile organization.  It turned out to be a good guess that paid dividends well beyond the investment.

We first implemented Release One – an estimate vs. actual record of attendance at all ceremonies and events.  This revealed three facts:

1.  At most of the events the attendance was not what was planned.
2.  That wasn’t all bad, because we discovered that teams often clogged up people’s calendars with meetings they didn’t need to attend (which explains why some of them were not showing up).
3. Some of the people attending didn’t need to be there, but they showed up anyway and ignored everyone (hey, it beats working!).

As soon as we started posting the scores in public team members came out of the woodwork! Those who were supposed to be there started showing up, and those whose attendance was superfluous self-selected out, removing waste from the value chain and increasing the bandwidth of the organization.

SCORE!  Instant improvement!

Having successfully spiked TeamScore in Release One, Release Two of our little experiment introduced a multiplier for engagement at each event.  If someone was unprepared, played with their phone the entire meeting, or constantly vanished to make a call (you know who you are!), we applied it to their portion of the average.  We didn’t report on individual scores, only the TeamScore. This introduced other ways for us to collaboratively set expectations, save money, and reduce our opportunity cost.  All because of GP2.7!

So learn to love it.  It can make the difference between saying your agile, and being agile.

© Copyright 2014: Process Assessment, Consulting & Training and Broadsword Solutions

“Just the FAQs” is written/edited by Pat O’Toole and Jeff Dalton.  Please contact the authors at pact.otoole@att.net and jeff@broadswordsolutions.com to suggest enhancements to their answers, or to provide an alternative response to the question posed.  New questions are also welcomed!