Top
Search
Exact matches only
Search in title
Search in content
Search in excerpt
Search in comments
Filter by Custom Post Type

Warning: A non-numeric value encountered in /home/premiosg/public_html/wp-content/themes/dcgsoftware/framework/modules/title/title-functions.php on line 465
Premios > Insights  > 5 CMMI Myths

5 CMMI Myths

In my opinion, CMMI still gets a bad rap sometimes. People who have been in development a long time remember the days where the model implementations were heavy, tedious and document-driven. Times have changed and so has the model. But there are those who still have misconceptions about what the model is and how it works.

Here are the top 5 CMMI Myths that still exist:

Myth 1: The model is only for software development

There are 3 constellations of the model; CMMI-SVCS, CMMI-ACQ and CMMI-DEV. Many people’s minds will automatically jump to software when they hear the word “development,” but there is more to the world than software. Sure, software may be used in just about everything we touch these days, but you also have to develop the product the software will operate.

If you look at the categories in the CMMI: Support, Process, Project and Engineering, you may struggle with the Support and Engineering categories over the others. Support process areas cover the configuration of your product, making key decisions on your product, measuring your status against your plans and goals and determining if you are following your processes. None of these areas scream software.

Now, keep an open mind and think “Engineering.” When you create a widget, do you have requirements for that widget (it has to be green, it has to be smaller than 5×10, etc.)? Wouldn’t you design what that widget is going to look like and then build the widget? I would hope that you would test your new widget before releasing it to unsuspecting purchasers of your widget. The requirements, design, development and test of your widget fall under Engineering, and we didn’t even have to build software!

Myth 2: Process needs to be heavy

Years ago most process people were of the mindset that process needed to include everything, even the kitchen sink, for it to be complete. But, over the last several years it has become more acceptable to create a reasonably sized process and still have it be not only useful, but also complete.

Answer the questions, “Who is doing it,” “What are they doing,” “When are they doing it (include the output and communication),” and “What are they doing with it?,” and you have provided the users with all the information they need. It is difficult to write for every single scenario that could arise, so DON’T. Allow resources to identify any special circumstances for their projects and move on.

Myth 3: The model will dictate “how” I do my job

The CMMI tells you what the best practices are and therefore “WHAT” you should do. Determining how to do it is up to your individual organization. No two companies are exactly the same and neither are their processes. Processes should be based on what works for your organization and nothing else.

Myth 4: I will have to change how I work

You might have to change how you work, yes, but change is not always a bad thing. I always recommend that the proper process development and implementation start with documenting what you currently do and then reviewing that against CMMI and determining the areas for improvement.

Areas of improvement may be things that you are not currently doing but should be doing. In some cases, the gap may be minor, which would have minimal impact on the change required. But sometimes change is necessary to move forward. I’ve had clients say, “I know it’s broken, but I’ve been doing it like that for years.” My response is usually something along the lines of, “Would you like your life to be easier?” Sometimes changing how you do things can make your life easier.

Myth 5: CMMI does NOT work in an Agile lifecycle

This is a discussion I love to have. For all those naysayers out there, Agile does not mean no process; it just means a different process. You still have a process to govern how your Agile teams will work. For instance, what Agile methodologies are being used? How long is an iteration? Who owns the product backlog? How are estimates completed? I could go on and on.

Now, most people will argue about CMMI making the projects produce an output of the process, and this is true, CMMI will want evidence of completion. BUT remember, nowhere in the model will it tell you what the evidence has to be, that is up to you. Think outside the box. I have many clients who will use post-it notes, whiteboards and a wall to capture the backlogs. Based on where the post-it is on the wall you can determine a task’s status. They capture the evidence by taking a picture and storing it on the document repository. Documentation problem solved!  Be creative and find solutions, but don’t walk away from the best practices of CMMI because of Agile.

Any other CMMI myths out there? Please share them in the comments!

Patricia Eglin
Process Improvement/Measurement Specialist, Certified Introduction to CMMI Instructor and Six Sigma Green Belt

Share
No Comments
Add Comment
Name*
Email*
Website