Wednesday, June 20, 2012

Continuously improve? What the $%^&! does THAT mean?

Hey, CMMI Appraiser – we are an electronics parts manufacturer in Virginia that recently merged with an organization that follows the CMMI. Even though they acquired us because of our Agile approach, my new manager doesn’t understand Scrum at all. He keeps asking me to push my team to “continuously improve” and “get better” at what they do, and “do more with less.” What the heck does that mean? We’re just trying to build great products, same as always. ~ Dan L.

Hey, Dan, so, your best isn’t good enough, you don’t know why,  and you don’t know what your manager's expectations are for what improvement looks like.  Hasn't he trained you to read his mind?  That would fall under GP2.5 by the way . . . .

I remember earlier in my career when I was the CIO of a company and I heard the same thing.  "Get better!  Make sure your team is continually improving!"  Like you, I said, What does that mean? Come in earlier? Work harder? Be more serious? (They actually said that to me one time. I responded by being LESS serious).

So you are not alone with this problem, my friend. The cool thing is, since then, I’ve done a lot of work with companies that have embraced the CMMI and Scrum in an effort to get better, and I've learned to help demystify things a bit.

In my opinion, the clearest way to think about Scrum and CMMI is in terms of process improvement, not running teams or projects. That keeps us focused on the only project we really care about, the one called, “Making our company Great.” Scrum can help companies adopt things like CMMI, ISO and continuous improvement programs in general.

Now, I don’t claim to be a mind-reader, but that could be exactly what your manager wants: Taking Agile and making it better by applying the lessons of the CMMI.  And conversely, taking the CMMI and making it better with Agile.  If you're getting a recursion headache now, don't worry.  It'll subside.

If so, he's onto something, although maybe not articulating it very well.  This is an idea I’m really passionate about. I believe all organizations can benefit from rethinking the CMMI and Scrum and how they work. It boils down to three simple concepts:

First, the CMMI is a behavioral model, not a process. It was intended to help make things better, a guide to continuously improve. It describes how great companies perform.

Second, as such, the CMMI doesn’t tell you HOW to get better. In fact, the CMMI doesn’t tell you how to do anything. It says, “Here’s what great companies have told us that they do.”  Your job is to apply these lessons to what you are doing in your context.  Tricky?  Yes, but well worth it.

Finally, the truth about CMMI and Scrum is that they are both the "same thing."  They are tools to help solve business problems. They help us improve  requirements churn and volatility, they help us meet schedule and budget, and they help us perform the work that we do every day.  They're not overhead - they're "underhead."

So relax, Dan.  You’ve got everything you need.  Leverage Scrum to get the best of the CMMI. And leverage the CMMI to get the best of Scrum.

If that’s what your manager is thinking, then I see a happy, productive company in your future.

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 for more information about running a successful CMMI program.


John Hunter said...

> What does that mean? Come in earlier?

> Work harder?

> Be more serious? (They actually said that to
> me one time. I responded by being LESS serious).
No, though like all these 3 if there was a specific issue on these topics fixing the issue might be needed but that is continually improving - that is just fixing something that was broken.

Continual improvement should result in the system being better. Fix the deploy system so fewer bugs get to production. Shorten the time to deploy. Decrease the time from bug notice to fix in production. Decrease turnover... They are not items of changing a person's behavior. They are fixes to the system that make all results from then on better. And you keep adding to that.

Anonymous said...

John, thanks for your comments!

Yes! We're in agreement, it's all about the system. But the system is only a model of a set of behaviors and how they interact. The system in itself produces nothing - humans produce everything (at least here on earth, as far as I know).

I've come to observe that people sometimes become fixated on "the system" and it becomes a distraction away from personal accountability and behavior. In this example it is ALL about "changing a person's behavior" You can't fix the system unless people change they way they act, can they?

There are WAY too many examples of consultants enticing their clients with "systems" that manifest themselves as tools, templates, binders, and libraries (the so-called "QMS approach") only to find almost no change in behaviors. This leads to the wallpaper effect - lots of evidence of improvement but no actual improvement in performance or product.

So in the end, when it's all said and done, personal behavior accounts for most things - and we can improve that by the implementation of a system.

John Hunter said...

In the hands of some the system seems out of the range of influence. They can use the system as an excuse to fail.

What I find is those that don't understand systems thinking often find the reason for a problem to be a person or a person's actions. If that is where they are, there organization is unlikely to improve rapidly. When you make changes to the processes and systems in the organization you get far more powerful results than when you tell people to be more careful, not be lazy and work harder.

Anonymous said...

Thanks John, and keep the comments coming!

I totally agree this is a "systems thinking" problem we are all trying to solve - and guess what? Not everyone is a systems thinker.