Archive for the ‘competitiveness’ Category

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.

SEPG-EUROPE Report… A lot to learn from here…

Friday, June 13th, 2008

Munich.  Refreshing!  That’s the word I’d use to summarize what I’ve experienced here this week.  By far, compared to similar conferences in the US, the most noticeable difference between the attendees here and elsewhere is that among the attendees here, they share an earnest desire to use CMMI to improve!  To dig into the model, reach beyond the descriptions of "levels" and really look at what they need to do to improve.  Really, improve.  

Pic of Watts -- KeynoteMuch of the "refreshment" came from the keynotes, actually.  Not that sessions I attended weren’t inconsistent with my observations, but the keynotes contained substance.

Everything from an exposé on policies that really zeroes-in on understanding their role in organizations, to ways in which traditional "need to know what this will cost and when it will be done" can be achieved on agile projects using, of all things, Earned Value and Function Points!

Among the keynotes (and others) were some very impressive explanations of exactly how process improvement (and CMMI, in particular) are necessary strategic assets that enable corporate goals.  How CMMI helps an organization satisfy and demonstrate it complies with external and internal standards.  How CMMI is helping an 1000+ person [yet still entrepreneurial] organization (that started as 13 people in 1999 and continues to grow @ a rate of 40 engineers/month worldwide) establish their organizational level capability to support frequent re-orgs (due to growth), international expansion, adapt new business goals, and introduce new regulatory and compliance standards.

There was even a session by a company who is forced, by contract, to reduce costs (or increase throughput) 10% per year or lose a multi-year multi-million USD contract.  And, of course, they were using CMMI (at ML5!) to do it and they explained how.

I’ve got blog materials for months!

But I’ll leave you with a few gems from Watts Humphrey himself:

  • Requirements ALWAYS change.
  • Time and Schedules are ALWAYS aggressive.
  • Resources will ALWAYS be tight.

These are the realities of technology projects.  You need a process that can address these realities and adapt to change.  A process that expects perfect requirements, plenty of time, and more than enough resources is a process destined to fail.

This, from the man many blame for coming up with "the worst thing that has ever happened to software."

Is it not clear yet folks that it’s not CMMI that’s the problem, just CMMI in the wrong hands, that’s the problem?

SEPG-Europe helped validate for me I’m not nuts.  Here are a few hundred people who really want to make things better.  From my visit at Seimens and my meal with the local Scrum users group, to all the folks I met and heard at the conference.  What it spells is this:  those who take processes seriously are preparing to take business away from those who don’t and keep it for a long time.

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.