CMMI and Agile Blog

January 11, 2018

Motivation for Essence in 7 Minutes

Over the next few weeks I am planning a series of short videos on selected Essence and Software Engineering topics.  Following are a few tentatively planned topics:

  • Using Essence Alphas like the Dashboard in Your Car
  • Scrum and Essence: An Example of What Practitioners Can Take with them for Life
  • Examples Demonstrating How Essence Checklists Are Different from Traditional Checklists
  • Examples Demonstrating How Essence Checklists Help Teams Become Self-Empowered
  • Examples Demonstrating How Essence Activity Spaces Can be Used in Industry
  • How Essence Can Help Teams Determine if they have a Leadership or a Management Problem
  • Examples of a Team Using Essence as a Reasoning Tool to Solve Common Problems
  • A Case Study of a Team that used Essence to Help Them Discover an Innovative Solution To a Difficult Problem
  • Examples of a Team Using Essence Competencies to Determine if They Have a Skills Problem
  • A Skill Practitioners Can Take with Them for Life: Making More Accurate Estimates using Essence

I start off this series this week with a 7 minute video motivating Essence.  As always feedback is encouraged.

If you are interested in learning more about how Scrum and Essence are partnering, checkout the latest announcement on the SEMAT website (


January 30, 2017

Avoiding two common software project troubled paths by “being agile” rather than “doing agile”

This week I want to talk to you about two common troubled project paths, and give you some simple tips to avoid both.

The first troubled path is putting too much effort into documentation. When you catch your project heading down this path stop and ask:

What is the driving need behind our documentation requirement?

Often there are two driving needs. First, your customer or senior management may be looking for some kind of assurance that the software team is doing the right things.  The second reason is to help users and maintainers once the software is deployed.

Unfortunately, traditional documentation isn’t very good at meeting either of these needs. It isn’t good at helping users and software maintainers because often it isn’t trusted to be kept up to date after delivery.  And, historically, documentation hasn’t been very useful to software teams at helping them create high quality software.

The second common trouble path is reacting to the first troubled path by declaring “we’re agile!” –and throwing out the essentials for high quality software along with the documentation.

Now, today, it is a fact that we are seeing more and more organizations trying to increase agility, but many of these same organizations are struggling to figure out how to “become agile” without jeopardizing essentials for success.  And in a moment I am going to explain more what I mean by that phrase “become agile” because I may not mean what you think.

But first, a little background. You may know that in previous blogs and publications I have talked about Essence.  Essence is a framework that captures essentials for high quality software in a simple way—and most important to today’s topic—those essentials are independent of the degree of agility you are driving for with your teams. Essence also includes a simple language to express practices on top of the essentials to give guidance to your teams.

Today I want to talk to you about three simple parts of an Essence practice and how these parts can help your teams find their right level of agility while not jeopardizing essentials for success and help you avoid both common troubled paths.

Those three parts are:

  • the purpose–or goal– of the practice;
  • the activities conducted as part of the practice;
  • the work products produced.

Activities in an Essence practice are what people actually do when carrying out a practice.  They can vary greatly in prescriptiveness. In other words, you can provide activities in your practice that just specify “what” people must do or you can be much more prescriptive specifying in detail the “how to” side of your practice activities.  Similarly, the degree of detail specified in a work product can vary greatly.

Now, let’s look at some examples from my “Upside Down” book.

In Story Two in Part I of my book you learn about a team that came up with an innovative approach to achieve the goal of their sprint review practice when they learned a key stakeholder could not attend the meeting. They actual got on an airplane and went to the client’s site to engage that customer and get their feedback.

The point I want to emphasize here is that the real goal of the sprint review practice wasn’t holding a meeting called a sprint review which is what too many teams get overly focused on when they blindly zero-in on following specified “how to” activities in highly prescriptive practices.

Stated differently, what we are seeing too often is teams falling into just “going through the motions” of prescribed activities. Other authors have referred to this as the difference between “being agile” and “doing agile”.   And, to be honest, I really didn’t understand this difference until I observed it in one of my own client organizations.

What you learn from that story I just referred to is how a team stays focused on the real goal and figures out a creative way to achieve that goal which is gaining the buy-in of key stakeholders—not holding a meeting called a sprint review.

In that same story you learn about a challenge the team faces with a tester having difficulty communicating with developers.  In this case, the team came up with an improved testing practice that included the activity of developers placing a note in the ticket to the tester.  The note in a ticket could be viewed as an example of a very lite work product—not a heavy documentthat helped the communication problem.

In this story it is important to understand that the goal of the testing practice wasn’t to create a note in a ticket.   The real goal was improving communication between developers and a tester. Placing a note in a ticket was just one possible activity that could help the team achieve the real goal of the practice.  And in this story you learn how the team understood that in certain situations if it made more sense to just get up from their workstation and go over and talk directly to the tester that was an option they could and should use.  This is a perfect example of “being agile” rather than “doing agile”.

What you learn from these stories is that where teams often get in trouble is when they start confusing the activity they conduct as part of a practice, or the work product they produce with the goal.  One simple way to help yourself is to keep asking yourself are we are getting too much into “doing agile” –  or just going through the motions of our rituals, such as sprint reviews even when the key people can’t attend?

Or are we “being agile” by keeping focused on the real goal and coming up with innovative solutions when necessary, such as finding creative ways to engage our stakeholders when they can’t make it to our sprint reviews, and getting up from our workstations and walking over to talk to a tester when their might be some risk of misunderstanding.

One caution here, if you decide to allow more choices in your team’s practice activities by making them less prescriptive– it is also highly encouraged that you provide clear limits to the activities, and coaching in these limits, so the team does not fall into chaos.

Always keep in mind that activities and work products are important parts of a practice, but they should never be confused with the goal of a practice.

When we see this confusion starting to happen it is often a sign that an organization is falling too much into the “doing agile.”

Use these simple practice tips when you are developing your practices and coaching your teams, and you might just find it easier than you think to avoid both common troubled project paths and find your right level of “being agile.”

January 26, 2017

Is Upside Down the key to Moving Forward?

Last week I promised in my next video and blog to explain two specific ways projects often get into trouble and give you some simple tips related to Essence that can help mitigate the risk of both.  I have had a busy week and so I am putting off that video and blog, but it will still be coming soon!

This week I was interviewed by Bill Fox from Container13; Exploring Forward-Thinking Workplaces

Bill asked me some very interesting questions.  One thing I loved about this interview was that I was able to tie in a strategy that may seem “upside down” that is used by the coaches of the 2016 Little League Baseball World Series Champions from Endwell, NY– which is just 6 miles from where I live.

Check out the interview at

I’ll try to get back on track soon!

January 15, 2017

A Key Value of Essence Related to Troubled Projects

I have been involved in the development of Essence since 2010 along with many other volunteers from around the world representing industry, academia and research.  And I have spoken on the subject of Essence at numerous universities and in many organizations including many of my own client organizations.  And the reaction I often get—to be frank—has been mixed.

Some people immediately see the potential value and react with comments like:

“Wow! I wish I knew about Essence when we were planning our last project.”

While others react with comments like:

“I don’t get it?” or

 “Why do we need it?” or

 “What’s so great about capturing what we’ve known for years?”

 Although it has taken me some time to figure it out, I now understand at least part of the reason why people react differently when first introduced to Essence.  The reason is because each person views Essence through the lens of their own experiences and perspective.  As an example, I can view my own clients as falling into two distinct types each with their own distinct experiences and perspective.

One type includes successful organizations with happy customers. These organizations have great people with proven track records of creating high quality software and meeting their cost, schedule and performance commitments within reasonable tolerances.  They come to me for coaching because they want to keep aware of the latest thinking and innovations in software development.  They do this because they know they have to keep getting better if they are to stay ahead of the competition.

The second type includes those who seek my coaching because their projects are in trouble.  Many in this group aren’t meeting their commitments and their customers aren’t happy and many don’t even know how they got into the mess they’re in.

Interestingly, it’s the first type who often respond when introduced to Essence with questions like,

“Why do we need it?” or

“What’s so great about capturing what we’ve known for years?”

 While the second type often respond with comments like,

 “I wish you were here and had told us about Essence when we were starting this project!”

When I help troubled projects I have found Essence to be an incredibly useful tool to help communicate to key organizational and project team leaders in a simple way where they went off course, and how to get back onto a healthy path.

This is a key value of Essence specifically related to troubled projects— it is a tool that can help you quickly pinpoint a problem area, and then drill down into that problem area, locating precisely what needs to be done, and then communicate the critical information to the people who need to know to get the project back on course.

I like to use a sports analogy to help explain this key value of Essence:

Most of us don’t appreciate a good referee in a well-played sporting event because we are focused on the game and the great performance of the players in the game.  But when the trouble starts, that is when the value of a good referee is recognized and appreciated by most of us.

What is interesting about this—and the parallel back to software– is that people who have only experienced successful software development efforts often don’t appreciate the value Essence can bring to– not only troubled projects– but to all projects, even the successful ones.  To help my successful clients understand this I like to ask them to think about the following:

Even though you are successful today, how confident are you that your next project will be as successful as your last?  And even for your current successful projects, how confident are you that the success you are currently experiencing will continue tomorrow?

 The point is that on all projects— successful or troubled—there is always risk of new circumstances and new challenges that can jeopardize future success.

 So what are you doing to mitigate that risk today?

While Essence clearly has proven itself in helping troubled projects today, its greatest value may actually lie in helping to mitigate the risk all software projects face of loss of essential software engineering activities that we now know exist and have captured in the simple Essence tool.

In my next video and blog I will explain two specific ways projects often get into trouble and a specific feature of Essence that can help mitigate the risk of both.

January 8, 2017

Helping Coaches Everywhere

In my last blog I highlighted how far a team can go to solve challenges on their own when given just a few simple principles and a clear goal.  But this doesn’t mean that teams don’t need coaching, tips, best practices and a structure that provides clear limits to how the team operates. This leads to the subject of this blog.

Besides the upside down principles, I also highlight in Part I of the book 18 coaching tips.  If you are wondering if a book that highlights coaching tips is for you, it is.  I believe everyone should view themselves as a coach.  But a big challenge most organizations face is how to communicate the right coaching tips to project personnel who need it, right when they need it.

Let me step back here, and tell you a little about my background.

I’ve been involved in the software business for over 40 years—the first 20 years as a software practitioner and the last 20 years as an independent consultant/coach.  And during the second half of my career as a coach I have often been called in to assist troubled projects.  One observation I have made about these troubled projects is that most of them fall into one or more of a surprisingly small set of common patterns.  But more importantly, when that pattern is detected in a timely manner, it’s usually not that difficult to steer the project back onto a healthy course. I’ve discussed this in previous writings and blogs. But this leads to an interesting question:

Wouldn’t it be great if there was an easy way to capture these common patterns and share them with coaches everywhere so more coaches could steer their project teams when needed keeping them on course?

This was my motivator for including a Part II in my book where I have framed the highlighted principles and coaching tips that have emerged from my stories in Part I within a framework called Essence.

If you have not heard of Essence yet, you have probably heard of the foundation from which it evolved, which I also explain in Part II of the book. I also explain with examples in Part II how Essence provides a simple and easy-to-use medium to communicate any organization’s practices, tips, principles, and checklists even among non-technical stakeholders.  This last point about stakeholders is particularly important. 

This is because when you read Part I you will learn how stakeholder issues related to understanding and knowing how to carry out project responsibilities is a repeating theme throughout many of my stories.  But, more importantly, it’s a repeating theme within many of those troubled projects I referred to.   

In my next Youtube and blog I share a personal story specifically related to troubled projects that can help you understand a key value of Essence that took me quite a while to fully comprehend and appreciate.

January 1, 2017

The Power of Principles

In my last blog I shared what motivated me to write my latest book, “It’s All Upside Down,” and I shared a little about what is in Part I of the book including some information about the 26 “upside down principles” (that aren’t really upside down).

In this blog I explain why I have chosen to focus on principles in the book rather than the more traditional approach of focusing on “best practices.”

So let me start this blog with a little background.

In 2015 I was fortunate to be invited to speak at the Agile Africa conference, and while attending the conference I listened to Kent Beck who gave a keynote address.  Kent talked about what he called policies – or what many of us might think of as principles–used at Facebook.

An example Kent referred to in his talk was “personal ownership”.  I found his talk fascinating.  The way Kent presented his material was by showing a single diagram with all of the principles visible.  He highlighted each principle he was about to talk about. Then he explained—using no extra slides, but just informally speaking– how the highlighted principle was implemented by practitioners at Facebook.

Listening to Kent using this presentation style gave me great insight into how work actually gets done at Facebook– and it struck me that he didn’t say anything about specific “best practices” used at Facebook.

This caused me to think about what the difference is between principles and practices.  This led me to the realization that principles are more closely aligned with goals, while practices focus more on approaches–or steps– to achieve a goal.

Now, please don’t jump to the wrong conclusion, or misunderstand what I am saying here.  Practices are certainly needed– especially for less experienced practitioners who need guidance in the steps to achieve a certain goal.  They are also needed for more experienced practitioners who often need reminders. However, there is a power in simply stated principles, along with a clear goal, that practices alone cannot provide.

For those who disagree, or challenge this assertion, I provide many examples in Part I of my book of the innovative activities teams come up with on their own to address their specific challenges.  And they do this with little help beyond having a clear goal and a few simple principles.

As an example, in Story Two of my book I share four specific examples of simple creative activities one of my clients came up with to solve specific challenges faced with regard to a stakeholder issue and a testing weakness the team knew existed.

Now, please understand that this is not to say that industry best practices cannot help teams with specific challenges.  But it is to say that best practices and lessons that were learned outside your organization can never replace listening to your teammates’ current specific challenges, brainstorming possible solutions to solve those challenges, and agreeing on specific courses of action.

Many might think that industry proven “best practices” would always trump whatever an individual team might come up with.  But my true stories demonstrate over and over again where this is often not the case.

Give your team a clear goal, and share some principles along with simple guidance in applying the principles, and you might just be surprised how far they can go to solving their challenges on their own.

I would also like to point out that I am not the first person to have observed the power principles.  Scott Ambler, one of the reviewers of my book, told me that with Disciplined Agile Delivery (DAD) they emphasize principles because people might actually read them and understand them.

In my next blog I will share with you a little bit about why I decided to include a Part II to my book, and what is in Part II.

December 27, 2016

What I’ve learned about software development and why it seems opposite to everything I was taught

In this blog I would like to share with you what motivated me to write my latest book, which is titled: “It’s All Upside Down”.  And I would like to tell you a little bit about what’s in Part I of the book.

So let’s start with the motivation. The title of this blog post is actually the subtitle of the book, which has a lot to do with my motivation for writing it.

In just the past few years I have made such drastic changes in how I help software development teams as a coach that it often appears what I am recommending to my clients is the complete opposite of many well established long held software engineering principles.

Now, in fact, my recommendations are not really in opposition to these principles at all—but they appear to be because what actually works in practice oftentimes isn’t what we think based on what many of us have been taught.

This was my major motivator for writing this book. I wanted to share true stories of what we have recently discovered really works for successful software development teams in practice.  There are eight stories in Part I of the book that all occurred in 2015 and 2016.

As I share the stories I also highlight 26—what I refer to as– “upside down” principles.  Now, the principles themselves are not really upside down.  What is really upside down is what many believe they need to do to effectively apply these principles.

To help communicate this message I focus each story around three key items:

  • First, the activities successful teams conduct in practice
  • Second, how much of these activities they conduct
  • And third, when they conduct each activity


I expect many readers will be surprised to learn how little time successful software development teams spend on certain activities that have traditionally received high focus, and–even  more importantly–  how much time is actually spent by successful teams on activities that traditionally have received little attention.

In closing this blog I would like to point out that I am certainly not the first person to have observed that what works best in practice often doesn’t match the theory.

It is also worth pointing out that this observation is not unique to software development. As the immortal New York Yankee baseball legend Yogi Berra once said:

“In theory there is no difference between theory and practice.  In practice there is.”

Now, in this blog I have referred to both principles and best practices.  In my next blog I will share with you why I focus more on principles in the book, and I will explain the power that principles can bring to a software development team’s performance.

Click to purchase the book

January 19, 2015

New Video on Practical Ways Teams Can Use Essence and New Published Paper on Essence

A few weeks ago I shared a You Tube video providing highlights of Part I of a talk on Essence (44 minutes) I gave at Binghamton University in November, 2014 to a group of Computer Science students.  Highlights from Part II of that talk are now available where you can learn practical ways software teams can use Essence including games they can play to help assess where they are, how to conduct a root cause analysis to isolate a problem, and how to use patterns to improve their performance.

Highlights of the talk can be found at:

The Part II highlights are 30 minutes in length and at the front of this video you can find where in the video the following 13 topics can be found:

  1. Assessment Poker
  2. Case Study Results Carnegie Mellon West
  3. Root Cause Analysis Example
  4. How Essence Differs from Lean Six Sigma
  5. Examples Using Activity Spaces
  6. Using Essence Competencies
  7. Another Example Using Activity Spaces
  8. Where Can Essence Help Most?
  9. Practice Slices and Patterns
  10.  Two types of information practitioners need
  11.  Examples of Patterns
  12.  A Closing Thought
  13.  How Students Are Using Essence at Binghamton University

I also have a new published paper on Essence titled,

A “Thinking Framework” to Power Software Development Team Performance, appearing in Crosstalk, The Journal of Defense Software Engineering in the Jan/Feb, 2015 edition.

February 3, 2010

Why Use the CMMI in an Agile Organization? And When You Shouldn’t

                                                     by Paul E. McMahon, PEM Systems

If you use an agile approach on most of your software projects and you are successful why would you consider using the CMMI Process Improvement framework? The natural thought many have is:

“Why should I care about the CMMI?” and

“Wouldn’t the CMMI just hurt our agility? and

“What value could the CMMI possibly add in our organization?”

First, I don’t believe the CMMI is right for every organization—especially if it is used the way I commonly see it used today focusing on just the attainment of a formal appraisal level.

Second, all the questions listed above should be asked and answered to your satisfaction before you decide to embark on a CMMI initiative regardless of how you intend to use it. It is true that the CMMI model could end up hurting your organization more than helping it. What I hope you can take away from this discussion is some assistance determining the answers to these questions with respect to your organization.

Answers To Key Questions For Your Organization
So let’s get back to those questions. The best way I know to help you get to the right answers is to share a couple of case studies of others who faced the same questions. The first case study is an organization I refer to as BOND. (For more details on the BOND Case Study refer to Chapters 4 and 5 in my book, “Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement” –Available from Addison-Wesley, June, 2010).

BOND was a successful agile organization, and the owners came to me and said they wanted to start a CMMI effort. The reason they gave is they were afraid at the pace they were growing they couldn’t sustain the way they were currently operating. A specific example is that the two owners did most of the new business work, and early on did most of the project management and interaction with the customers. But now they were growing rapidly due to their success and they knew they needed to delegate more of these responsibilities deeper into the organization. But they also made it very clear that they didn’t want to lose the successful Agile culture that had brought them their current success and growth.

This brings us to the first key point that they stressed with me:

Make sure you don’t break what is already working well and got us where we are today.

To achieve this we instituted a key rule in applying the model.

Key Rule: Only change behavior if there is a clear problem in the organization that we are solving.

To implement this rule I told the CMMI Process Improvement team that we will add nothing to the current agile processes using the argument that we had to do it because the CMMI dictates it. We did add what we called “stretch points” but only when we could explain in the training WHY this helped the organization. This strategy is part of the answer to the question:

“Wouldn’t the CMMI just hurt our agility?”

The answer is, yes it can, if you use it the wrong way—that is by dictating practices because you think the CMMI requires it. When you take this approach—which many organizations seem to do today–you are indeed putting your agile success at risk.

The strategy we employed would not allow that to occur, and contrary to what many belief this strategy is actually the best strategy to actually succeed with a formal appraisal and rating.

So now what I want to focus on is the “stretches” we all agreed to, and the rationale that was used during training to explain how these stretches helped the organization. BOND was a successful Agile organization, but we did find areas that all agreed where the organization needed to stretch to help the organization sustain its agility and success as it continued to grow. So what we are now going to talk about will help you answer those other two questions:

Why Should I Care About The CMMI? And

“What Value Could the CMMI possibly Add to Our Organization?”

Keep in mind that I don’t believe the CMMI is for every organization. For example, you may not need the same stretches BOND needed because every organization has a different situation. The right answer for you is likely to be different from the right answer for BOND.

What the CMMI model does for us is to help us ask the right questions. It shouldn’t be used as a set of dictated practices which is a common mistake applying the model in many organizations.

Knowing When to “Stretch” In A Successful Agile Organization
When I started helping BOND one of the first things I did was spend time talking to the workers and conducting an informal gap analysis against the CMMI model. Because the organization was growing rapidly the two owners had already started delegating Project Management responsibilities deeper into the organization. In my interviews a common concern I heard was that many of the next tier leaders were being expected to pick up these added management responsibilities, but they weren’t being relieved of their previous responsibilities and they were unsure exactly what was now expected of them as the organization was growing.

A “stretch point” all agreed could help this organization was to define roles and responsibilities in the organization. Out of this activity came a new role we called the Project Engineer. This role was essentially that of a project manager. We also instituted training of Project Engineers so they would know their expectations and have the skills needed to carry them out.

As the organization grew it also became clear that how communication occurred between these new Project Engineers and Senior Management needed to be more clearly defined. When the organization was small most communication occurred verbally, but now with the growth verbal communication was starting to break down as people were becoming busy and forgetting to follow up on actions that may have resulted from a brief hall way conversation. This led to another “stretch point” to define clearly Senior Management Briefs and what information should be in these briefs and to start conducting them on a regular basis.

Most of the Projects at BOND—when the organization was small– ran on their own with little sharing of information across projects. They used many common agile practices, but they had no formal training in these practices within the organization. When new people came into the organization they learned by watching and talking to others. Lessons from one project were learned by others only when they were informally shared such as through lunch time discussions.

Because BOND was successful we didn’t want to change many of these informal approaches that were working. But because they were growing it was becoming clear to many in the organization that these same informal mechanisms that worked well when there was less than twenty people in the organization didn’t work so well when they were getting close to one hundred people.

As a result we kept many of the informal strategies that were working but we wrote them down and trained and institutionalized them in support of the agile culture. Our approach was not to change behaviors that were working, but to support current behaviors where communication was starting to breakdown due to growth. This is the answer to the questions:

“Why Should I Care About the CMMI?” and

“What Value Could The CMMI Bring To Our Organization?”

Stated a little differently, the value the CMMI brings is to help us ask the right questions at the right time and put the right improvements in place so we know what to do when things don’t go exactly according to the plan. Now lets, talk a little more about the value of written processes.

The Value of Written Processes: What To Do When Things Don’t Go Right
Let me now share a little about another case study that I refer to as NANO to help you see another aspect of the potential value of the CMMI in an Agile organization (For more details on the NANO Case Study refer to Chapter 6 in “Integrating CMMI and Agile Development).

BOND was a successful agile organization that was applying Agile practices as intended. But not all organizations who refer to themselves as “agile” implement agile practices correctly.

There are also what I call “agile like” or “wannabe agile” organizations. These are organizations, that are trying to be agile, but are missing key ingredients of true agility. The CMMI can help these “wannabe agile” organizations find their right level of agility. NANO is a successful “agile-like” organization that is growing, but knows it can’t sustain the way it is operating.

Let me give one story from NANO which demonstrates how the CMMI can help an “agile-like” organization. One of the Senior technical leaders at NANO told me he believed in process, but didn’t think the work he did was relevant to process. I asked him to explain. He said he often has to work out a design for a new approach on short notice and the way he does it is a very dynamic and creative process. He explained that often the director would call him up with a problem that needed a fast solution. After taking a couple of days to analyze the problem he would call the director back and they would brainstorm the ideas over the phone. Then the director, if he liked it, might ask him to write up his ideas in a white paper. The director would email it to others to get their comments. If they liked it he would next take it to a lab and prototype it before making any final decisions. He then said he thought what he had described should make it clear to me why he couldn’t follow a process.

What became clear to me after listening to this was his belief that any kind of activity that involved thinking, brainstorming and learning was outside the bounds of process. He seemed to believe that until you could give some one exact “cookie cutter” steps that required no further decisions any work should not fall under process. At the conclusion I told him while he didn’t think he followed a process, he actually did follow a sound process. He had described it to me including the stakeholders (reviewers), and products (white paper, results of prototype). I also shared that just because he didn’t know where it would lead was no reason not to follow a documented process.

By writing it down others could learn and follow it too. We also could ensure we remembered all the people who should review it ahead of time, and we could write down the criteria he uses to make decisions so others might know and follow it as well. I often see stakeholder involvement weakness in agile organizations, especially those organizations that are growing rapidly.
This relates to a common mis-belief that processes are only for well defined “cookie cutter” activities. In reality a good CMMI level 3 process helps you the most when things don’t go according to the plan because it helps you remember the things we often forget under stress which is common on aggressively scheduled high risk efforts.

So far we have been focusing on how the CMMI can help an agile organization. So when shouldn’t an organization use the CMMI?

When Shouldn’t I Use the CMMI?
If your organization is not growing, if your workforce is stable and you aren’t bringing in new people, if everyone knows their role, and everyone knows who to involve and when to involve them– then the CMMI may not be right for your organization. But also think about the risk to your future survival if you are answering all these questions in the affirmative.  Change is essential to survival.  By asking the right questions and thinking about the factors specific to your organization you can make the best decision to help your organization sustain its success. 

For more information on CMMI and Agile refer to

Blog at