Archive for the ‘value’ Category

CMMI is overrated and unnecessary…

Saturday, December 1st, 2007

This entry over at OpenSource Connections got me thinking.

They’re absolutely right.

I’ve even said as much myself at NDIA’s 6th CMMI Technology Conference in 2006 in response to a question.

The question was something like, Are you saying that CMMI isn’t necessary if our company believes we are fine the way we are, and we don’t see any need to improve?

My answer was pretty much, "yes".  I added, if a company is OK with the status quo and competition isn’t a concern, and their leadership doesn’t believe in the business rule-of-thumb about not moving forward is the same as falling behind… then yes, CMMI is overrated and unnecessary…

… for companies who don’t worry about lottery-sensitive individuals, or rapid growth, or shifting products, or who are quite content with the strength of their client relationships that they need not worry anyone will step in and oust them or bring in competition.

I’m always thrilled when I come upon a software company that has its act together like OpenSource Connections seems to have.  However, as regular readers know, I’m not as thrilled that the folks over there have an entirely inaccurate perception of CMMI as the ability "to check certain boxes about whether or not we have a laundry list of processes documented and implemented."

CMMI’s language certainly makes one believe the assumption in the model is that people aren’t doing the right things.  However, the exact wrong way to view or use CMMI is as a list of check-boxes.  Anyone found performing an appraisal in that way ought to be reported to the SEI.

But that’s not the point of this post.  The point here is that you should read the OpenSource Connections post.  Even with their misunderstandings they make good points.

One point about the reality of level-rated organizations (even high-maturity ones) can still deliver junk is right on the money.  Not having done an in-depth study myself — not sure anyone has — I’d venture that most level-rated organizations delivering junk took the check-box approach to CMMI, whereas the ones who took a business-value approach to CMMI actually deliver customer delight and high profits.

Another point about process having a place in agility was also crucial to giving their entry credibility.  Recognizing that even small, agile organizations do have processes and rely on them for success is a think of beauty.  More organizations would be successful if they understood this much about themselves.

Their shortcomings in understanding CMMI are excusable, the points I wish to surface have to do with a few aspects they didn’t address.

One thing CMMI helps avoid (but, by no means is the only solution for) are issues with know-how that’s locked in individuals’ heads.  Or for dealing with a customer-base that expects specific people to be doing the work.  Even with this CMMI isn’t required, and certainly not an entire maturity-level rating, but if an organization is facing these issues and doesn’t have any idea what to do about it, parts of CMMI can help.

Which brings me to my second point for the moment.  Maturity Levels aren’t the only way to use CMMI.  In fact, even with capable organizations, many find that being able to borrow practices and goals from particular process areas may help them fine-tune an already working operation.

Whether an organization bothers to pursue even a Capability Level for any process area(s) isn’t even where I’m going.  Being "rated" has nothing to do with being capable or mature at development.  CMMI has value whether or not organizations choose to get rated; whether or not they choose to use entire maturity levels, entire capability levels, entire process areas, or even entire goals.  CMMI can add value one practice at a time.

Organizations that have their act together could probably do very well with an appraisal and learn a lot about themselves.  Limiting the value of CMMI to whether or not the organization has had an appraisal limits more than CMMI; it limits the business value of creating the efficiencies, knowledge longevity, and ROI for looking into their own processes at all.

Posted in value | Comments Off

Expand the scope of "value".

Sunday, October 7th, 2007

I get common resistance from agile proponents that part of the agile philosophy is to only perform activities that add value to the product, and thereby (the assumption is) to the client. This is often a stumbling block for the "lean" folks too.

The argument goes along the lines of: much of the CMMI practices to "maintain" and even many of the practices to "establish" certain work items don’t add value. If not, why do them?

It’s a strong case. But strong cases for not doing practices don’t make for organizations that can get through a SCAMPI (CMMI appraisal) and end with a maturity level rating.*

So what is there for an organization to do?

There are two ways (non-exhaustive and not mutually exclusive) to re-factor this thinking, both of which involve adding long-term value in addition to immediate value:

1) Adding value to the organization, and
2) Adding value to the future product (or, to the product in the future).

In the first approach, process activities are seen as adding value beyond the immediate project. Process activities are seen as an investment in the efficiency and productivity of future projects. And, on sufficiently long projects, these activities can provide feedback in time to make a difference to the projects underway and from which the process data is being collected. This approach adds value to the business in terms of know-how, intellectual property and competitive edge.

The second approach, while similar to the first is product-focused. In this view, the value in doing the process activities is in being able to reduce maintenance costs, make updates/upgrades less cumbersome or expensive and make the product more extensible. This often goes handily with allowing the developer to be different from the operator, the maintainer, or the help desk.

Many paradigms of process improvement use the metaphor of "throwing the product over the wall" as a means to describe what happens when products are developed in a serial, production-line fashion and not as an integrated, high-trust, highly communicative team (sound familiar?). The very antithesis of agile development.

Well, here’s a wake-up call for some people, including self-proclaimed agile developers: the "wall" eliminated by integrated and agile development teams is not only between steps in the development life cycle. Sometimes the wall that needs eliminating is temporal. That is, stop throwing your well-tested, peer-reviewed, non-wasteful code over the wall for someone in the future to have to deal with. Most of us have had to make sense of someone else’s spaghetti code at one point or another and we shouldn’t be the ones to create it even if we did so by being lean and agile today while sacrificing the value of the product in the future.

So, the value we’re trying to eek out of our process activities ought to take this sort of long-term view of "value" Some also refer to this as "Total Cost of Ownership" or TCO. Process activities ought to be calculated on the basis of TCO for the organization and the product.

In both approaches, the value being added to the organization as well as to the product is a reduction in waste. Companies don’t become lean over night and they don’t become great at agile practices with 2 days of stand-up meetings or one 30 day sprint. Often taking the time to identify, record, be methodical about, and update the organization’s approaches can help find what works and eliminate what doesn’t.

Really…. CMMI isn’t what complicates this, it’s not understanding CMMI that owns that job.

* Let’s be clear about something… Achieving a maturity level (or capability level) rating should not be any organization’s goal. Improvement should be. PLENTY of benefit, value and improvement can be had without *ever* being appraised and/or without ever attaining a "level" rating. However, for obvious reasons, achieving ratings has other value, such as being able to compete for certain customers and in certain markets.

Posted in TCO, Total Cost of Ownership, competitiveness, lean, long term, organization, value, waste | Comments Off