Why do CMMI Appraisal costs vary so widely?

"Your price is 120% higher than the last guy that was in here!" the potential client cried, "what's up with that?  Shouldn't a SCAMPI A be the same from each Lead Appraiser?  I mean, IT'S A STANDARD for heaven's sake!"

Not being my first rodeo, or nearly the first time I'd heard someone say this, I just sat back, smiled, and asked her " What are you trying to accomplish, really?  I'm not talking about the 'level," I mean what are you really trying to do here?"

That caught her a little off guard.  "What do you mean, 'accomplish?'  None of the other guys asked me that.  They just gave me a price."

Ah ha.....

There are a lot of reasons for differences in pricing.  Quality of service, obviously, is one.  Experience.  Credibility. Timing, size, and most importantly, business goals.  That last one is a little harder to predict.

"But I thought my business goal was to get ML3?" my potential (and future) client stammered.  "My boss told me I needed to get it by the end of the year or else I wouldn't get my bonus."  The poor lady seemed pretty frustrated with me, and appeared as if she was about to throw me out and hire the cheap guy from Appraisals-R-Us.

"Why do you think your boss wants you to get this? I asked.

"So we can bid on government work!" She answered.

"And the government wants you to be CMMI ML3 because.....?" I quickly added.

"uhhhh.  I'm not sure, It's just an RFP requirement" she replied.

"Look,  I'm sure the government's reason for asking you to do this has nothing to do with yet another plaque on your wall in the lobby ('Plaque Buildup'), but has EVERYTHING to do with ensuring that your company can handle what's about to happen should you win one of those sweet IDIQs.  They want to make sure your process systems can handle the stress, and deliver results."

"OK," she said. "But how does creating a bunch or process and documents help me do that?"

BINGO!  They don't!

They only help you pass an appraisal (maybe), but it's not nearly enough.  For true performance improvement, you need an expert in BOTH CMMI and Performance on your side.    The appraisal itself is perfunctory - a single event, a moment in time, a gate to get through.  The harder, more valuable stuff comes long before the appraisal.  But the time the appraisal comes you should have already won.

It's kind of like that movie "Rocky."  You could have  skipped right to the fight with no manager (which Rocky considered), participate in the fight, and get beaten badly (worse than he was!).  Or you could be more like the famed "Italian Stallion," who took his training to heart, made the hard choices, ran all his steps, and savored victory while bounding up the steps of the Philadelphia Library and doing his victory dance.

He had already won by that point!  We knew the rest.



And that's what you need to do with CMMI.  Work with someone who will take you to victory long before the appraisal event occurs.  The appraisal should be a non-event for you, not something you prepare for.  It should be more "bring it on" than "I hope we pass!"  "Passing" should never be part of your aspiration or goal - greatness should be.  Of course you're going to pass - you're now an awesome company!

There are some Lead Appraisers who don't get this - too many, actually.  They're satisfied to leave it to you, just conduct an appraisal, give you a certificate, and walk away without providing any valuable advice or insights.  But a great Lead Appraiser is an advisor and counselor, as well as a mentor, coach, and teacher who knows that the path to greatness lies on the far side of innovation, hard work, and discipline - and has the ideas you need to make it happen.

Don't waste your time with someone who doesn't get that.   That's WHY they're so cheap.

By the way, here's what to look for in a great Lead Appraiser:

- Has proven Experience
- Understands your methods, tools, and domain
- Understands your business
- Is comfortable interacting with Senior Management, as well as all levels of the company
- Freely offers ideas and techniques for improving working conditions and processes
- Is a teacher, coach, and mentor - not just a "consultant" who tells you what they think you should do
- Takes time to brainstorm ideas and solutions to your biggest problems
- Offers other valuable insight and ideas for business problems you are having

Best of luck to all of you, and here's to a great 2019!

How do we satisfy our State Government client who is asking us to “be more agile?”

Hey CMMI Appraiser,

We are working with the CIO of our State Agency, who is a big believer in organizational performance improvement and is always pushing us to be better. He just came back from NASCIO and heard that vendors need to start being "agile." Our team is smart and talented. We do daily meetings, collaborate, and meet with our customer all the time. Isn't this ok?  If not this, what is agile? ~ S.T 

Hey, ST,

Thank you for writing in.  Different people mean different things when they say they want to be agile. Let's dive into this.

When people say, "be more agile," sometime they mean, "deliver faster and cheaper." And when (too many) software engineers and developers think about "being more agile," they sometimes think it means, “no oversight or documentation!”

What does it ACTUALLY mean? Agility’s greatest strength, and the reason for its extraordinary success, is an intense focus on learning and adapting. Your customer probably wants you to keep learning and adapting your service to meet his evolving needs.

For you to be agile, then, you need to approach Agile as a student.

OK – now what?

In order to study and learn the discipline of agility, it helps to think of the approach as a three-tiered architecture of Agile Values, Agile Methods and Agile Techniques.

1. Agile Values

This tier defines the values that we agree to embrace. Our values are the things that are most important to us. These are the things that your organization needs to stay focused on, and your customer wants you to stay focused on.

Some of these agile values are transparency, collaboration, hiring the right people, fail-fast, inspect and adapt, share the work, and others.  The most commonly discussed values can be found at http://agilemanifesto.org/.

Side note: recently when I presented about Agile Values at a conference, a skeptical manager approached me and insisted that traditional Waterfall-style projects can easily have these same values.

I said, “That’s true. And guess what? When they do, they just called well-run projects!”  These values are universal. Unfortunately, "waterfall" methods and techniques don't always align well, or "trace," to the values.  So that's why we have . . .

2. Agile Methods

The second tier in the Agile architecture defines the WAY we do work - sequence, events, and ceremonies - and that WAY is derived from the values in Tier 1. All of the methods selected should adhere to the values. We call this having "values traceability."

Clients who work with Broadsword often hear me talk about "the WAY." Your "way" is derived from the values and methods use choose to select and embrace

Methods describe the sequence, interfaces, style, and the workflow of much of what we do. In this context, I use the words "method" or "framework" while I'm working with our clients. I think of them as synonymous.

In an Agile environment, the most common methods (frameworks) are Scrum, Extreme Programming, Spiral and Crystal, with the first two being the most prevalent.

For example, Scrum defines ceremonies, artifacts, and roles, and presents a basic sequence  (sprints, et al) for us to deliver our service or product in the context of values.

3. Agile Techniques

Techniques are the things we do every day, within the selected method, in adherence with the values. There are some techniques that are unique to methods, and some that span the entire family of Agile frameworks.

Techniques normally associated with Agile methods include:

• retrospectives
• Backlog grooming ("story time")
• User Story development
• Story Point estimation
• Planning Poker
• Fibonacci estimation
• Sprint Review (Demo) 
• Refactoring
• Test Driven Development
• BDD
• Spring / Iteration Planning

Being the third tier of an integrated architecture, a technique alone, without the corresponding methods and values (such as "we do a daily meeting") does not make you "agile," although it's better than NOT meeting everyday.

As I said above, you need to approach Agile as a student.

If you want to become a student, join us on November 7th @ 8:30 am – November 8th @ 4:00 pm (2 days). Here’s the link: 

Sign up for the Agile Scrum Learning Experience!

Hope to see you in class!

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about running a successful CMMI program.

Check out Ask The CMMI Appraiser TV!

That's right!  We're now have our own YouTube Channel!

https://www.youtube.com/channel/UCYOtm0XSGzxoxy8O4ME9XMQ

Below, you’ll find a list of current "Ask The CMMI Appraiser" episodes. Click on the title to view the video, or use the link above to see them all!

Video 1:  Should We Make Everyone Follow the Same Process

Video 2:  Don’t Run Your Business by Process Models

Video 3:  What’s the #1 Problem We Face With CMMI?

Video 4:  If We Buy a CMMI Level 5 Company, Are We Level 5?

Video 5:  How Do We Convince Management to Buy Into CMMI?

Video 6:  On Building Airplanes and Observing Process Infrastructure

Video 7:  What are the Generic Practices For?

Video 8:  Making Scrum Stronger With CMMI: The Generic Practices

Video 9:  Introduction to CMMI-DEV Training

Video 10:  CMMIxs for Xtra-Small Companies

Video 11:  CMMI Myths for Xtra-Small Companies:  Episode Two

Video 12:  The Large Adopters Will Change Agile!

Video 13:  CMMI and Agile are about the Same Thing!

Video 14:  How Disciplined is Agile?

Video 15:  Are You Really Agile?

Video 16:  What’s Different about Documentation in Agile Projects?

Video 17:  Do Agile Teams Use Process?

Video 18:  Be Agile by Tuesday. Huh?

Video 19:  What Can We Do About Organizational Type Mismatch?

Video 20:  Can We Run the Company Using Scrum?

Video 21:  What Should Our Process Architecture Look Like?

Video 22:  What’s the big deal about planning poker?

Video 23:  Will Our Agile Values Translate Company-wide?

Video 24:  How to Develop Requirements in an Agile Setting?

Video 25:  What Is CMMI?

Video 26:  What’s the Secret to Passing an Appraisal?

Video 27:  How are music and technology alike?

Video 28:  How do you create competencies as a business?

Video 29:  How do we create competencies as a team?

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information.

Why do a lot of people think CMMI and Agile don’t go together?

Hey, CMMI Appraiser: CMMI with Agile? A lot of people think they don’t go together. Tell me about that. ~ Geri Winters, Business Agility Conference

Dear Readers, on September 23-24, in Austin, Texas, I will deliver the Keynote Address at the Business Agility Conference. The organizer of the event, Geri Winters, founder and CTO for Wyyzzk, and a seasoned corporate technology and agile strategist, interviewed me for a webisode on Blab.im. Read a summary of a segment of our conversation below, or click to watch the whole interview. Enjoy! 

Hey, Geri. 

The more we use the CMMI, and the more we work with companies that are using the CMMI, the more we realize that this is a model that's about how great companies perform. But you are correct. There is a misperception about CMMI that it wouldn’t work well with agile.

We see it this way. CMMI is nothing more than a model for improving what you are ALREADY doing. There is no conflict between CMMI and any development framework or set of techniques like Scrum or XP. 

In fact, the CMMI and agile are more alike than they are different. Both were designed to solve business problems. Both came into being the same way, too.

In developing the Agile Manifesto, Ken Schwaber, Jeff Sutherland, Ron Jefferies and others sat around in a smoke teepee on top of a mountain – so the stories goes – and came up with a list of things that great companies do. The SEI was in more of a professional office setting when they came up with CMMI. But in both cases, smart people sat around, saying, “What do great companies do? What makes them successful?”

They came up with a list that says, great companies do all of this stuff. The CMMI list is very comprehensive, and the agile list is much broader, but not as deep. 

Several years ago, we brought them together by pioneering “agileCMMI,” an iterative and incremental method for designing and deploying process solutions. With agileCMMI, we helped organizations take a “Scrum-like” approach to understanding the CMMI framework, and apply it to whatever they were working on.

See, CMMI improves the teams that are using Scrum (or any other technique, for that matter) because, in the case of Scrum, you have a minimalist approach to developing products in an iterative and incremental way. But Scrum does not cover everything required to drive performance, organization-wide. Many such best-practices exist within the CMMI.

So whether their goals are to successfully deliver software, achieve a CMMI Maturity Level, or get on the path to becoming a great company, the agileCMMI approach helps organizations improve incrementally and in a lightweight, useful way.

Business owners and leaders can learn more about putting their companies on the path to greatness at the Business Agility Conference. I’m really looking forward to it!

REGISTRATION CLOSES IN 10 DAYS!

Sign up for the Business Agility Conference in Austin, TX on September 23 and 24, 2015. Register now and take 15% off!

http://www.thefluidagile.com/BusinessAgilityConference

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about running a successful CMMI and performance improvement program.

How can we get value from Requirements Development within Agile teams?

[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. This month Jeff writes about using language that makes sense in an agile environment. In other words, Jeff translates practices in Requirements Development to "stuff that needs to happen." Take it away, Jeff! ~ the CMMI Appraiser]

We’ve studied the practices in Requirements Development, but they don’t seem very “agile.” We know they don’t describe specific techniques we should use, but it’s hard to see how we can align this process area with what we’re doing on our Scrum teams.

JEFF: As Gloria Estefan likes to sing “… the words get in the waaaay …”

When I am working with Scrum teams, I steer clear from terms that are tied to process models or alternative cultures (“hey, what the heck are product-component requirements?”). These terms are all well and good for textbooks and classrooms, but someday somebody is going to get hurt!

I try to adapt my language to local conditions when working with Agile teams, and my favorite word tends to be “stuff.” For instance, the “needs” we elicit from our customers (RD SP1.1) are the collection of stuff that our customers say they want (but will change). Customer Requirements (RD SP1.2) are what we eventually get as we learn more about the stuff they want (but that’ll change too), and then we validate requirements to make sure we can build some cool stuff that they find useful (and are willing to pay for).

To help translate the practices in Requirements Development into “stuff that needs to happen” I usually suggest that agile teams implement two things:  a three-tiered architecture that brings clarity to their requirements process and a cascading “definition of done” that helps ensure that the requirements provide a solid foundation for estimation, design, and development.

Note: I will admit that the notion of applying a “definition of done” to the creation of User Stories is not strictly “agile,” but there is no reason we shouldn’t use agile to help improve agile, right?

Tier 1  The Product Backlog represents what the customer has asked for in prioritized order, and the CMMI provides information and guidance for some ways that we might extract and compile the content in RD SP1.1 and SP1.2. Because we are often asked to provide a “rough order of magnitude” estimate for the product backlog (“we don’t know what we want, but how much will it cost?”), we usually use Wide-Band Delphi, a collaborative, experience-based estimation game that is played in three rounds. It is ideal for agile teams because of its similarity to other agile estimation methods, but uses effort, not story points, as its unit of measure. Government and large corporate customers haven’t quite figured out how to deal with the relative sizing of story points yet  – but we’re making progress!

Tier 2:  Epics draw on the Product Backlog to depict scenarios written from the user perspective, and may represent many User Stories. The CMMI provides guidance in both RD SP1.2 and RD SP2.1 that can help strengthen the narrative so that both the customer and the Scrum team can benefit from increased clarity. Epics are often described as just “big user stories,” but that definition has been driving teams to ignore them altogether in their rush to get to the specific User Stories that they can sink their teeth into. This trend is unfortunate because Epics play an important validation role in uncovering defects in the product backlog long before story development begins. Once Epics are complete, further estimation is needed to prioritize the workload across sprints and releases, so this tier introduces relative sizing models like The Fibonacci Game (“Team Estimation Game”), while leaving the door open for refinement of the effort-based estimate developed at Tier one.

Tier 3:  User Stories are user-centric narratives with identified tasks that can be completed within a single sprint. RD SP 2.1 and RD SP 2.2 both provide valuable information for assisting in the development of stronger user stories, while RD SP2.3 can help uncover stories that are not typically represented in the Product Backlog. Because the Scrum team has beaten a direct path from need to epic to user story to task, it now has a thorough understanding of the functionality to be delivered in the next sprint (“value”), so for the third tier, Planning Poker becomes the preferred choice for story point estimation.

So that brings us to the application of a cascading “definition of done” that applies to all three tiers of the architecture. To make this real, I encourage agile teams to collaborate on a set of questions to be asked at each tier as they progress through the process of developing their User Stories. These questions help validate each tier, and assist the team in increasing their knowledge of the functionality being requested. There are no “right” questions here, but REQM SP1.1 and RD SG3 can provide us with some good suggestions to get started. Some of the questions might be:

• Is there an agreed-upon narrative for the Epic or User Story?
• Is the Epic or User Story from the right source?
• Is the Epic or User Story clearly stated so that all stakeholders understand it?
• Is a test case written for the Epic or User Story?
• Will funding levels still support the intended functionality?
• Will the intended functionality meet performance requirements?
• Have we done this before and is historical data available?
• Do we have an experienced team delivering this Epic or User Story?
• Is there substantial risk that needs to be mitigated for this Epic or User Story?

Understanding the status of each question provides Scrum teams with a useful tool to analyze risk for both story comprehension and sprint planning. One lightweight technique to consider is a “Confidence Matrix” that establishes a binary “strong-weak” indicator for each question. This helps teams calculate a Confidence Score and estimation multiplier for each User Story that can serve as one input into understanding the story and identifying defects before they are baked in. As teams iterate through subsequent sprints, and learn to leverage the Confidence Score as a team, they can experiment with weighted scoring if they desire more fidelity.

These are but a few small examples of leveraging the CMMI to improve requirements development in an agile environment. Since CMMI brings you the most value by helping you improve what you already do, agile teams will get even more from the model after deploying a solid requirements architecture that helps them deliver high-quality User Stories in a predictable way. Once they have that, they can look deeper into the CMMI to make it even better. Onward!

© Copyright 2014: Process Assessment, Consulting & Training and Broadsword Solutions
“Just the FAQs” is written/edited by Jeff Dalton  and Pat O’Toole.  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!

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. 

Global Adoption of CMMI Performance Improvement Framework Continues to Rise

Reposted from: BusinessWire · Feb. 24, 2014 | Last Updated: Feb. 24, 2014 11:31 AM ET  

CMMI Institute announced today that a record number of Capability Maturity Model Integration (CMMI) appraisals were completed in 2013 as organizations across the globe elevate organizational performance by adopting CMMI. The company also released the findings of a customer satisfaction survey using the Net Promoter® Score (NPS) methodology in which individuals who utilize CMMI rated CMMI as the world class means of improving organizational performance.

CMMI appraisals allow companies to measure their capability maturity against a defined framework of best practices. More than 1,600 appraisals were completed in 2013, the most ever done in one year and an 11% increase over 2012, the previous record year for appraisals. Of the 2013 appraisals nearly 40% were completed in China, where the widespread adoption of CMMI is driving economic growth and development across the region.

For complete story go to: http://t.co/LijVKa7L0Y

Just as a side-note, as a Lead Appraiser at Broadsword, I personally delivered 10 of those SCAMPI A's last year, in addition to about a dozen Class B and fifteen Class C Appraisals.

CMMI ROCKS!

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about engineering strategy, performance innovation , software process improvement and running a successful CMMI program.

Are they Alternative Practices, or just innovative?

[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. This month Jeff takes the helm with an article about Alternative Practices.  Take it away! ~ the CMMI Appraiser]

This week I completed my 88th presentation of “Introduction to CMMI-DEV” and, needless to say, my evolution from slide-reader to evangelist took place long ago.

Me (using my best evangelical, big tent voice):  “Goals are WHAAAAAT?”

Them (in a postulate tone): “R-E-Q-U-I-R-E-D!”

Me: “Practices are WHAAAAAT?” 

Them: “E-X-P-E-C-T-E-D! “

Me: “Everything else?” 

Me: “G-O-O-D   I-N-F-O-R-M-A-T-I-O-N! “  Whoo hoooo!

I followed that up with my usual sermon about what “expected” really means - it’s what the CMMI generally expects to see in order to achieve a given goal within the context of the business model.  Since we conduct appraisals through the examination of practices and the “evidence” they collectively produce, it’s usually a hot topic during my classes that are often filled with potential Appraisal Team Members.

In the back of the room, a young woman (who I could have sworn had just been nodding off) raised her hand and asked, “what if we’re just smarter than you are?” 

Rut roh!  Cue the music!

She was making a great point.  I’ve been lucky enough to work with people who are almost universally smarter than I am, and with so many approaches to systems and software engineering executed across so many cultures, I am always learning about innovative ways to accomplish a task. Lead Appraiser’s haven’t seen everything, and the very fact that the practices are “expected” is recognition of that.  These are, of course, known as “Alternative Practices.”

The CMMI glossary defines an alternative practice as something that is a “substitute” for one or more Specific or Generic Practices.  

This leads us to Rule #1: “Sometimes there is another way.”

In general, the CMMI does a reasonably good job of anticipating the practices a project will employ to achieve a particular Goal, and they are described in general enough terms that they apply to most situations.  In fact, some of the practices are SO general and high-level, that it leads to confusion in the market about what projects teams are supposed to do!

That leads to Rule #2: “There are not many other ways.”

Every few years this topic is hotly debated on one of the CMMI message boards that has not yet been shut down due to the religious extremism exhibited by its members, and they always end up in the same place:

Rule #3: “Just ‘cause it’s interesting doesn’t mean you’ve discovered an alternative.”

My good friend and “Just the FAQs” writing partner, Pat O’Toole, dug into this topic a few years back in one of his useful ATLAS studies.  He asked the community to provide examples of “alternative practices” that they had run across in their travels.  His data suggests that they are few and far between – 5 out of 44 candidates were, in fact, agreed to by the community-at-large to be true alternatives to the CMMI’s Specific and Generic Practices.  And some of those are, IMHO, still open for debate.

Pat calls those 39 remaining practices (and I presume many others he has run across) “alternative implementations,” and I use the term “innovative implementations.” Teams do often come up with innovative ideas for behaviors and processes, but that, in itself, does not mean that an alternative has been discovered (nor does it mean that the authors of the CMMI thought of that innovative implementation when they designed the model!).

In searching for examples, people sometimes get hung up on the sequence and grouping of practices, and they find themselves searching for that direct one-to-one alternative to a single practice.  Save yourself some time because . . .

This leads to Rule #4: “Alternatives rarely map one-to-one with the CMMI practices.”

There are often many-to-many, or at least a “many-to-one,” relationships between any alternative and a single or group practices, creating even a greater opportunity for confusion between “alternative” and “innovative.”

In my experience, the most commonly referenced “alternatives” are related to one “agile” practice or another.  Perhaps this is because they are gaining in popularity, (or because they just aspire to be different…), but team members often refer to agile estimation techniques – planning poker or Fibonacci sequencing for example -  as an alternative to the CMMI’s estimation practices in Project Planning.  I mean – who wants to do THOSE THINGS?  But even though these are both VERY innovative approaches to estimation, they are simply collaborative techniques based on sizing that fit quite nicely into the “expected” category.

Another common suggestion is that the use of “sprints” (scrum) or “iterations” (XP) are an alternative to the CMMI’s expectation that a “lifecycle” be defined and employed (PP, OPD, IPM, et al).   Ditto for Kanban for software.  Again, while these are an innovation in the software product management, these are still a kind of “lifecycle” – albeit conceptually very different from what some of us experienced while we were coming up in the industry.

Here’s some others I often hear:

Pair programming?  Nope, peer reviews.

Retrospectives? Uh uh.  Collect Process Related Experiences

Backlog Grooming? Ah ha!  That must be one!  It’s REALLY alternative!  Nope.  It’s an innovative combination of Requirements Management, Validation, and Project Planning.  Good stuff for sure – just not an alternative practice.

While Alternative Practices are sometimes treated as secret black magic that only the most seasoned Lead Appraisers can interpret, my experience has been quite the opposite…..

This leads Rule #5 – the final rule:  “Most alternative practices are mundane and administrative.”

“What?  After all this you tell me that the mythical “Alternative Practice” is BORING?”

I’m afraid that’s mostly true.  Maybe not all of them (since I’m not smart enough to know them all), but the most common ones seem to be pretty unimpressive.

·         Your customer directs you to use a supplier

·         Your customer tells you what the architecture and technology will be

·         The government “helps” you by giving you the schedule and budget they want you to use

·         Another company does independent V&V

·         On a 10-year maintenance project you use a “push and pop” ticketing system since a WBS with life-cycles is not that useful

On the other hand, if your customer changes the requirements the night before launch, it is NEITHER alternative nor innovative!

Good luck – and focus on innovation, not alternatives!

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

Pat O'Toole and Jeff Dalton's "Just the FAQs #2: What's the Deal with REQM SP1.1?"

[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.

You could also try turning it into a question by asking: "they want us to build WHAAAAAT?"

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. 

2012 saw more CMMI Appraisals than any previous years

Dear Readers,

According to the CMMI Institute's 2013 CMMI Profile Reports, there were more appraisals conducted in 2013 than in any other previous year.  This would indicate that, far from "not being relevant" as is sometimes claimed in the tech media,  the CMMI is increasing in popularity - even in a down economy.    I've been writing about this for some time since the best time to turn to proven optimization models is in a down economy.  With the new adopters being primary smaller organizations (see two posts below), we're seeing more new activity than ever before.  Here's the data:

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, ScrumMaster, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff pioneered agileCMMI, the leading methodology for incremental and iterative process improvement. He has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

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.

Pilot Testing: A Tale of Two Companies

Hey, CMMI Appraiser, in my last company, we tested all of our new processes before deploying them. My new boss doesn’t think piloting is necessary, and I don’t have any hard data or evidence to fall back on. What can I say to change her mind? ~ Kim L.

Hey, Kim– great to hear that you are being an advocate for pilot testing in your new company! Helping people transform company culture with CMMI is an area of expertise of Laura Adkins, a Senior CMMI Consultant with Broadsword. Laura does amazing work with companies who are trying to institutionalize new processes within the Agile and CMMI frameworks. Take it away, Laura! ~ The CMMI Appraiser 

Thank you, CMMI Appraiser!

Kim, hard evidence can be gathered to prove the value of piloting in your organization. But rather than trying to convince your boss with a lot of facts and data, I’d recommend telling her a story.

I call it, “The tale of two companies …”

Once upon a time, there were two companies: The Foolish Company and the Wise Company. The Foolish Company believed they needed to achieve CMMI Maturity Level 3 right away. So their quality group got to work designing the Foolish Company’s new CMMI-based processes. They didn’t have time to consult process users. Instead, they went forward designing large volumes of process assets, and immediately deployed them to all of their process users.

The Foolish Company chose to build their process on a foundation of sand because it was much quicker.

Now the Wise Company had a different approach. The Wise Company was a good company that wanted to be great. After learning about CMMI, they selected it as their process framework because they believed in the model’s best practices. The Wise Company commissioned small groups of employees to define processes that would improve their performance. These small groups designed processes iteratively so they would be “Just Enough, Not Too Much”. Before deploying their new processes, the Wise Company tried them out on projects of varying sizes and types.

The Wise Company chose to build their process on a foundation of rock because it was much stronger.

Let’s fast-forward several months and see what became of the two companies’ very different process improvement planning efforts.

The Foolish Company, which chose to build its process on a foundation of sand, because it was much quicker, didn’t take the time to pilot test their processes before releasing them. The team tried to use the new processes, but found defects and areas that they missed. After just a few weeks, the Foolish Company realized that their processes were not designed for small software maintenance projects. Since the Foolish Company is primarily in the business of performing software maintenance, they had to go back and re-design their processes to meet the needs of small projects. Months later, they were still in the rework mode …

The Wise Company, which chose to build their process on a foundation of rock because it was much stronger, spent time pilot testing their new processes on projects of varying sizes and types. The Wise Company listened to their pilot participants and made the changes they suggested. The Wise Company caught some areas that needed to be changed, implemented the change, and are going forward with the deployment, releasing the new processes with confidence that they will work.

Ask your boss: Which company are we going to be?

The real value of pilot testing is it helps accelerate the institutionalization of new processes. By planning and conducting a process pilot, your company can use the feedback from pilot process-related experiences to update your assets … and be a Wise Company.

Encourage your boss to look back through our blog posts on pilot testing, Kim. We hope we’ve shared enough tools, tips and guidance on validating process that the value of testing will be clear. If you need any more help convincing her, you know where to find us!

Like this blog? Forward to your nearest engineering or software exec!

Laura Adkins is a Senior CMMI Consultant with Broadsword Solutions Corporation. She has years of real world experience using pilot testing strategies and tactics to help her clients achieve their goals. Laura also uses the CMMI, in partnership with her clients, to set-up, monitor, and sustain process improvement programs.

Visit www.broadswordsolutions.com for more information about running a successful CMMI program.

Can you tell us how to get a CMMI Level in the next three weeks?

Dear Appraiser,

Emergency!  We've won a new contract and they tell us we have to be CMMI ML3 in the next three weeks.  We don't know anything about CMMI, but my boss says if we use Agile we can make it.  Can you tell us how to do that? ~ Desperate

Dear Desperate:

No.


Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about engineering strategy, performance innovation , software process improvement and running a successful CMMI program.