[Dear Readers, our good friend Pat O’Toole, CMMI expert and seasoned consultant, is collaborating with us on a new 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. To kick off the series in November, Pat addressed the frequently asked CMMI-related question - "Why is REQM at ML2 while RD is at ML3?" This month Jeff Dalton returns the serve with another one: "What's the Deal with REQM SP1.1: Understand Requirements?" ~ the CMMI Appraiser]
Take it away Jeff!
Last year, while conducting a final findings briefing for a CMMI-DEV Appraisal, an attendee blurted out “what’s the deal with REQM SP1.1? We sit around and discuss requirements all the time – why doesn’t this ‘qualify’ for ‘Understand Requirements?’”
Had she been present at the preliminary findings briefing we could have had a conversation about how they evaluate requirements, or maybe even discussed the “definition of done.” But because we were in the presence of 150 people and executive management, it was, as the kids like to say, “awkward.”
As it turns out, REQM SP1.1 is more complicated than it sounds.
The attendee didn’t give me much breathing room before moving in for the kill. “Last month you told us,” she insisted, “that the subpractices are meant to help understand intent and are not ‘required,’ yet the weakness YOU noted is from the subpractices. Aren’t you just ‘dinging’ us for something that isn’t required?”
Yikes!
She was right. The weakness identified by the team was indeed derived from the subpractices, in particular the ones about defining and using criteria to evaluate requirements.
The attendee folded her arms, sat back and waited for me to mount my defense.
Shifting into “teacher-mode” seemed like the best approach, so I began asking “the questions.”
Does the requirement meet the “definition of done?” Is it ambiguous? (cue groans from the audience). Can it be designed and delivered? Without knowing those things, can we understand what we REALLY need to build?
I like to turn the subpractices into these types of questions because it helps re-direct team members from “compliance-mode” to “improvement-mode,” and leads them to discover something that they probably already knew.
“But you SAID!” protested the attendee, in a last ditch effort to persuade me to acquiesce and soften the weakness.
Yes I did. But we don’t approach this with an attorney’s magnifying glass. We’re coaches, mentors, and advisors – not lawyers. I ALSO said that doing what’s smart for your company should dictate how the practices are interpreted. In this case, they were receiving complex requirements from many different sources and had a geographically dispersed team that had not worked together in the past. In this context, the intent of REQM SP1.1 is precisely defined by the subpractices and examples, and appraisal teams should embrace this guidance, even if they believe, as I do, that it is only intended to be informative. REQM SP1.1 is about more than just “understand requirements.”
I like to think of REQM SP1.1 as “Evaluate and Understand the Complete Requirements.” During the “Introduction to CMMI” class I introduce the Agile concept of “Definition of Done” to illustrate that this presents us with an opportunity to achieve consensus, avoid re-work, lower risk, and understand the “complete” requirement.
Please contact the authors at pact.otoole@att.net and jeff@broadsword.com to suggest enhancements to their answers, or to provide an alternative response to the question posed. New questions are also welcomed!
Visit www.broadswordsolutions.com for more information about engineering strategy, performance innovation , software process improvement and running a successful CMMI program.
To download eBooks about CMMI, visit Jeff’s Author Page on Amazon.
No comments:
Post a Comment