Archive for the ‘excellence’ Category

Short-Cut to CMMI: Lean First

Thursday, March 29th, 2012

Want fast, easy CMMI ratings?  Even high maturity?

First, implement lean, Goldratt’s TOC, Deming’s ideas, Kanban, and other related concepts, then get busy with CMMI.

What you may not know is that lean is easier, faster, and generates better performance results sooner than CMMI.

Lean improves delivery issues sooner than process improvement alone.  Improved deliveries improves revenues, stabilizes cash flow, increases margin, makes customers happier and results in more sales.

In other words, lean means better flow and better flow means better business.

CMMI is great, but is often attempted as a first line of offense to issues it’s not meant to deal with.  CMMI is meant to improve flow, not define it, and, lean helps define flow.
(Yes, I know I said "theory of constraints" twice.)

Assuming there are unfulfilled orders in the sales pipeline, lack of revenue is due to lack of flow.  Typically, this is due more to what’s in the flow, how much is in it, and the clarity and cleanliness of how the operation’s flow is aligned.  Using CMMI to "fix" issues with flow is like using the Brownian motion of steeping tea to power a random-number generator.  It’s just too much too soon.  Process issues are themselves symptoms of flow issues.

Deal with the symptoms first.  Then, tackle the processes.

Two events to put on your radar:

Lean Software and Systems Conference: Boston, 13-18 May (Lean Camp & Lean Action Kitchen, Sunday, Conference Monday-Wednesday, and Tutorials Thursday & Friday).  I’m helping to organize and speaking at the conference, and running a tutorial on this topic on Thursday.

Kanban Change Agent Masterclass: Miami, 23-25 May.  I’ll be participating as a special guest to demonstrate how Kanban helps achieve CMMI ratings, including High Maturity.

Doing Agile CMMI without “Doing” Agile or CMMI

Monday, November 8th, 2010

There’s an under-appreciated reality of what either agile or CMMI can accomplish for an organization.  In particular, it’s not as much about what either accomplishes for an organization as much as it is about what an organization does for itself that achieves agility and systemic improvement.

It seems to be a decades-old issue that many technology-oriented companies, and, it seems, especially software companies, struggle with organizing and managing operations towards excellence.  I can’t even begin to dig into any reasons why this is so, but there may be some truth to the stereotype about technology people not being good with business and/or people. ;-)

I’ve found something fascinating that is fairly consistent across many companies I’ve visited or discussed with colleagues.  What’s fascinating about it is not only the consistency across multiple fields, industries, verticals, and national boundaries, but that it reinforces a position I’ve taken since beginning my career.  That position is the afore-mentioned “under-appreciated reality”:

Aligning the organization with specific business goals and providing a supportive culture
leads to broad behaviors at all levels that result in high performance.

OK.  So, that may not seem earth-shattering.  But there’s a lot in this statement about agile and CMMI that too many organizations to “get”.  And, this is where all the anecdotal evidence from the many companies comes into play:

Organizations with a culture of excellence generate behaviors (including setting and pursuing specific business goals) that achieve agility and systemic improvement without specifically setting out to achieve either “agile” or “CMMI”.

Throughout my earlier career, I was routinely frustrated by “training” that provided me with specific tools and techniques for dealing with “many common” situations – pretty much all of which were cultural, interpersonal, and otherwise based on human behavior.  The cases, examples, and solutions all felt very canned and contrived.  Why?  Because, in effect, they were.  They were very specific to the context and would only solve issues in that context.  What the examples lacked – and by extension, the entire course – was fundamental tools with which to deal with situations that were not neatly boxed into the provided context.  In other words, these training courses provided practices. These practices work in explicit situations, but they fail to provide the basis upon which those practices were built.  Without such a basis, I and other consumers of this “training” could not address real situations that didn’t match the training’s canned scenarios.

“Doing” agile or CMMI by “doing” their respective practices results in exactly the same limited benefits.

Making agile or CMMI “about agile” or “about CMMI” accomplishes little value and lots of frustration.  These are only practices.  Practices are devoid of context.  A culture of excellence and an explicit business case to pursue improvements provide the necessary context.

We see this all the time.  For example, for decades in the West mathematics was taught in a way left many students wondering, “what will I do with this?”  (This may still be true in many places.)  It was/is taught without any context to how it can help them better analyze and understand their world.  As a result, Western students have historically been less interested in math, do less well in math tests, and are less inclined to study in fields heavily dependent on math.  All due to being taught math for math’s sake and not as a means to a beneficial end.

Medicine is also taught this way around the world.  Leading too many doctors to seeing patients as packages “symptoms” and “illnesses” rather than as people who need help.  Scientific exploration often gets caught up in the same quandary.  Exploration is the goal, if you’re looking for a specific answer, it’s research.  When you’re trying to create a specific solution it’s development.  Mixing-up “exploration” with R&D will frequently result in missing interesting findings in pursuit of narrow objectives.

In agile practices, what’s more important: doing Scrum or delivering value?  Pair programming, or reducing defects?  Maximizing code coverage in unit tests or testing the right parts of the product?  “Doing” Scrum, pairing, and automating unit tests are intended to deliver more product of high value, sooner.  Focusing on the practices and not what’s best for the customer are missing the point of these practices.  Same with CMMI.

What are the economics of your core operation?  Not just what your group costs to operate on a monthly basis, but what unit of value is produced for any given unit of time?  How do you know?  Why do you believe your data is reliable?  The ability to make decisions relies on data and when the data is unreliable, decisions, plans and anything else that relies on the data is questionable and risky.

It turns out (not surprisingly) that when a group focuses on what’s important AND has the economic data to reliably understand the behavior of their operation, it aligns their actions with the very same goals set-forth in both agile and CMMI.

Focusing on the right things in your operation will cause behaviors that achieve agility and “rate well” against CMMI.  Whether or not you’re even trying to “do” agile or CMMI.

CMMI Limits Growth

Friday, October 8th, 2010

If you use CMMI for the ratings only you will be limiting your growth.  CMMI can only put you on a trajectory for growth but can’t determine what that trajectory should be.  For that, executives must identify business goals they want to aspire to and then you can use CMMI to help achieve them.  In particular, goals in terms of time to market, cycle time, product or service quality, efficiency, customer delight, response time… anything that equates with operational excellence and profit.  Without these business goals and the measures to determine how well you’re moving towards them, CMMI will just frustrate your people and waste your money.

If you don’t value the idea of raising profits by lowering operational cost, then don’t bother with CMMI.  If all you want is a rating, then you will never see any benefits from CMMI.  Either you establish business growth goals, or CMMI will just eat away at your business.RatingvsGrowth  If getting leaner isn’t appealing, stay away from CMMI.

It makes me sick every time I hear a company complain how much it costs to maintain their CMMI “rating”.  It pains me to hear of companies with recent ratings who are still habitually over budget and behind schedule, and not getting better.  I’m bewildered by companies afraid to make changes to the operations for fear of “losing” their ratings.  What these real-life I’m-not-making-this-up scenarios all have in common is that every one of these situations shares the attribute of using CMMI for the ratings and not the business value of growth.

I’ll take some blame for that on behalf of the other hundreds of consultants and appraisers out there.  Sure, I can’t prevent executives from being short-sighted and ADHD, but I can do my part for allowing executives to go forth with misuse of CMMI knowing that they will ultimately fail to see any benefits.  Is that how I personally work?  Of course not, but that is how too many other consultants and appraisers work, so on their behalf, I’ll fall on the sword.  Shame on us for allowing companies to use CMMI in stupid ways when we know it’s a bad idea. 

CostvsProfitOn the other hand, what can we consultants and appraisers do when executives willingly take the “ratings over growth” route?  When executives are not willing to stand up for what’s best for the business?  When the executives are not motivated to pursue operational excellence?  At the same time, we’ve all been using the wrong language with CMMI.  Who the heck wants to hear about “process improvement”?!?  That’s a lot like wanting to hear “you need to go on a diet and get more exercise”.  Who wants that?

What executives need to hear and see is that CMMI for the ratings limits growth and is worthless but CMMI in support of increasing profits is priceless.

Use CMMI for a rating only and your business will stop its growth right where the rating starts.