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. 

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!

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.

Where can I find resources to help me use CMMI and Agile?

Dear Appraiser,

When we read the CMMI it doesn't appear to support the use of Agile.  But on your blog you talk about it all the time.  Where can I find more information?  ~Tyra

Tyra,

You're right!  The CMMI does not read like an "agile friendly" model.  In fact, it's methodology agnostic, and doesn't read like ANY methodology  (although if it "leans" one way or the other, it's towards the "waterfall" world).  

The other wrinkle is that, unlike agile, it doesn't speak directly to values - although they are embedded throughout the model more than you might think.

The trick to making this all work is to understand the INTENT of the practices, goals, and process areas, instead of reading it literally and trying to "comply" with what is written.

In my talk on "Agile Resiliency" (which I'm giving at the Boston SPIN next week), I discuss turning the CMMI into a set of questions, instead of a set of statements.  "HOW do we estimate the scope of the project?" instead of "Establish a WBS to estimate the scope of the project."  If you do it with story points and planning poker, that's OK!

For example, a "Work Breakdown Structure," used for estimating the scope of the project in the CMMI ("PP SP1.1"), is intended to scope out the project size, along with all of it's major components.  In an agile world, a product backlog, set of epics, and maybe a product plan ALSO do these things.  So, if they're done well, they will meet the INTENT of the CMMI, if not the literal words in the book.

For more information check out some of the many posts on this blog about Agile and CMMI.  You can also check out:


Cutter IT Journal article on Scrum and CMMI that I wrote (free download): http://www.cutter.com/offers/agiledalton.html

SEI Technical Report I co-wrote for the SEI on CMMI and Agile  (free download):  http://broadswordsolutions.com/wp-content/uploads/2011/02/CMMIandAGILE.pdf

My eBooks on Amazon: www.broadswordsolutions.com/cmmiebooks

Hillel Glazer's excellent blog: www.agileCMMI.com

Good luck!

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.

What are the CMMI Generic Practices for?

Hey, CMMI Appraiser – why is it that we have to worry so much about these Generic Practices? Seems like a big headache to me - Jim W, Minneapolis, MN

Greetings, Jim! Thank you for submitting the first question to be answered in our new CMMI-TV series! Like this blog, CMMI-TV is a place where we can add value to the engineering and software development community by offering advice on engineering strategy, performance innovation and software process improvement. Below is a video clip with my answer to your question, followed by a synopsis of my response. Enjoy!

OVERVIEW

The CMMI (Capability Maturity Model Integration), is a model that helps us build better software and run better projects.

The Generic Practices apply to all process areas in the CMMI – which is why they should have been named the Most Important Practices.

Regardless of what type of method, technique or process that you use, the Generic Practices can really help jump start the success of those practices.

The Generic Practices apply to activities that the organization performs, not necessarily the individual projects. The guidance provided by the Generic Practice includes but is not limited to:

SETTING EXPECTATIONS

• How long are our Sprints?
• What kind of retrospectives do we have?
• What kind of code reviews should we run?
• Should we comment our code, and how should we comment it?

PLANNING

• How many Sprints are we going to have?
• How many phases are we going to have?
• How many releases are we going to have?
• What kind of requirements management tools are we going to use?

ASSIGNING RESPONSIBILITY

• Who is going to be involved?
• When are they going to be involved?

PROVIDING TRAINING

• Are we providing training? For example, if I’m going to ask you to do Planning Poker and use it as a way to estimate the size of a project or a particular user story, do I plan to train you on how to use those tools?

MONITORING THE HEALTH OF THE PROCESS

• How is the process working?
• Are we getting value out of our sprints, phases and the tools that we are using, out of the techniques that we are employing?
• If we aren’t getting value, why not? And if not, let’s make them better!
• Are people actually using these processes?
• If they aren’t, why not?

MANAGEMENT

• Is management paying attention to all of this data?
• Are they doing something about it to make the company an even better company?

CONSTANTLY IMPROVING

• Are we constantly improving the processes?

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

Don't miss our CMMI Training class coming up in Virginia February 11-14, 2013
Introduction to CMMI-DEV v1.3. Register at www.broadswordsolutions.com

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 the CMMI improve Agile methods?

At a recent Agile Leaders Network (ALN) meeting in Washington, D.C. on CMMI and Scrum,  the Lead Appraiser answered an attendee's question about how the CMMI can improve Agile methods.  Enjoy!

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

Don't miss our CMMI Training class coming up in Virginia February 11-14, 2013

Introduction to CMMI-DEV v1.3.  Register at www.broadswordsolutions.com

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.

The Art of CMMI: Tactical Dispositions

[Our good friend Shawn Rapjack, CMMI expert and seasoned consultant, is back with a another installation on CMMI based on Sun Tzu's "The Art of War: Tactical Dispositions."  We're excited that Shawn has agreed to share segments of his article with you here on "Ask the CMMI Appraiser"]

Continuing the ‘Art of CMMI’ discussion, let’s join the battle with the Art of War’s fourth chapter, ‘Tactical Dispositions’ and alternately named, ‘Positioning’.  A theme for this chapter is ‘defense’, and specifically: ‘not creating opportunities for the enemy’.  But what does this mean for us CMMI practitioners?

It means playing it safe, being anticipatory, and addressing risk.  Sun Tzu summarizes:

Making no mistakes is what establishes the certainty of victory, for it means conquering an enemy that is already defeated.

And,

Thus it is that in war the victorious strategist only seeks battle after the victory has been won, whereas he who is destined to defeat first fights and afterwards looks for victory

Such cautionary forethought is captured throughout the CMMI.   For example, managing risk provides a mechanism to anticipate possible roadblocks. As with battlefield tactics, risks are identified and plans are implemented to counteract or mitigate their impact. 

Project planning also requires significant ‘defensive posturing’.  Managers need to consider future ‘attacks’ on their project well into the future.  These could be:  scheduling conflicts, resource allocation conflicts, budget issues, etc.  Remember that:

To see victory only when it is within the ken of the common herd is not the acme of excellence.

To lift an autumn hair is no sign of great strength; to see the sun and moon is no sign of sharp sight; to hear the noise of thunder is no sign of a quick ear.

And hence the modern saying:  ‘You have a fine grasp of the obvious.’ If a manager only anticipates the obvious hurdles (‘uh oh! Budgets!’), they will miss the countless obscure ‘gotchas’ (weather-related delays, delivery schedule conflicts, etc.) that could befall their program.

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 do I develop a pilot plan for our new CMMI-based processes?

Dear CMMI Appraiser, we are getting ready for our first SCAMPI-A appraisal, and have differing opinions among the managers about how to develop a pilot plan for our new CMMI-based processes. What do you recommend for a mid-sized life sciences product company in Dayton, Ohio? ~ Hersch E.

Dear Hersch, great question! The answer will apply not just to Ohio-based life sciences product companies like yours, but for any company seeking information on developing a pilot plan for any new CMMI-based processes. Of course, we don't like to think of them as "CMMI Process," but your own processes super-charged by the CMMI . . .but I digress.  Let me pass it along to Laura Adkins, a Senior CMMI Consultant with Broadsword, who does amazing work with companies who are piloting processes that are strengthened by the CMMI, in Ohio and throughout North America. Take it away, Laura! ~ The CMMI Appraiser

Thank you, CMMI Appraiser!

Hersch, at Broadsword we pilot all of the processes we develop as part of our agileCMMI methodology, before deploying them. The reason? You’ll hear us saying over and over that CMMI is not about “getting a CMMI rating.” It’s about changing your company to radically improve performance. The advantage of using an agileCMMI approach to radically improve performance is that it incrementally decreases risk and ensures your success.

As you go about developing a pilot program for your new CMMI-based processes, we recommend that you create a formal, written Process Pilot Plan that clearly spells out what your expectations are and who is included.

Here’s an example Table of Contents from a Process Pilot Plan:

As you see, beyond the agileCMMI methodology, we also recommend that your Process Pilot Plan includes the following elements: Scope, Approach, Duration and Timing, and Pilot Testing Participants.

SCOPE -- The Scope is to determine which processes were recently developed, which ones will be piloted, and which ones won’t. For example, sometimes you are developing processes that don’t necessarily have to be piloted, for example, an annual process, which is hard to do in a pilot scenario. After considering what was developed and what is applicable to be piloted, you then need to determine who will do the piloting whether it is user groups or projects.

It’s possible for a SEPG or user group to pilot a process. Some processes are tailored at the organizational level. More commonly however, Scope deals with projects, not user groups. Pilot testing at the project level must include a project that is going to be executing the processes that you are piloting in the next six weeks. In other words, look for projects that align with the processes that are being piloted.

APPROACH – After determining Scope, you’ll define your Approach. This includes documenting how to train and mentor pilot program participants, and how to collect feedback, as follows:

• To train pilot participants, you don’t necessarily need formal training. Often a dry run on your training will suffice for your first time presenting it. 
• To mentor pilot participants, you’ll need to select mentors and assign them to pilot projects. Your expectations to them need to be clear. 
• To collect feedback, it’s important to talk about how you are going to collect feedback. It can be done via email, or feedback can be captured in a document. Some companies allow participants to post feedback in blog posts. Your Approach defines how you will collect those experiences: where the feedback will be stored, what format it will be in and what medium will you use to collect it are all things that should be considered.

DURATION AND TIMING – On the topic of duration and timing, we recommend that you focus on being really specific. When is the pilot test starting? When is it ending? What is your duration? When is training going to occur? You must be clear on that, and break the pilot down into specific tasks.

PILOT TESTING PARTICIPANTS – The last aspect of defining your Process Pilot Plan is to identify in detail who will participate. You need to select your project(s) and list out all of the people that are involved in the project. These are your primary contacts. If you’ve identified groups or departments, you would list them out here. Even if they are playing a supporting role, you would want to identify them. Anyone who could potentially impact the pilot or provide any kind of feedback, you would want to identify them here, as well as your mentors from the process side of it.

These are the elements of your Process Pilot Plan. Good luck, Hersch! Let me know how it goes.

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.

Labels: CMMI, CMMI Appraisal, CMMI Assessment, CMMI Assessor, CMMI Certification, CMMI Consultant, CMMI Consulting, CMMI Training, Scrum, Scrum CMMI, Pilot testing, CMMI Ohio, CMMI Appraisal Ohio, life sciences product company Ohio