A Paradigm Shift Towards Agile

 

In a recent pair of "sales" meetings with CMMI-related prospective clients we encountered an interesting but unfortunately not terribly surprising commonality.

In both meetings, we learned that we had provided the prospect(s) with completely new and highly valuable information about their choice/need to pursue CMMI practices. This is the kind of outcome we at Entinex like... to demonstrate our value by being proactive and educational in our meetings. "Sales" appointments for Entinex are as much our interview of the prospect as it is their interview of us.

Here's the unfortunate but not terribly surprising commonality: Ours wasn't the first company to be interviewed by either prospect. And, the "highly valuable information" we were providing our prospects, to us, was actually rather fundamental. In our minds, we can't go forward with an engagement without the kind of knowledge from our clients that this "highly valuable information" provides *us* -- let alone what it means for the client. We guess this is what sets us apart in our industry and what allows us to be more "agile" than our colleagues.

In fact, after communicating the information, each client's response/reaction was "That's a really good question. We don't know the answer. We didn't know we had a choice. We have a choice?"

So... what was this critical piece of information?

Basically, it's along the lines of asking our prospects, "what exactly is *your* client asking from *you*? And, have you considered taking this alternate approach towards meeting that expectation?"

?8^(blank stare of bewilderment)

Yes, valued readers, we were simply taking our clients' customers priorities and values into consideration before we set about to solve their process needs.
(The actual question, it seems, must be a very proprietary thing since we sound like the only company asking it, so... I must put on my "CEO hat" once in a while and actually try to keep to ourselves some modicum of market differentiation -- you understand.)

We also noted that in each case, the prospect assumed we'd be giving them a formal, all-too-common Powerpoint song and dance. Again, that's not our style, and, it's not focusing our attention where it matters most: on the client. Instead we simply sat down to talk about their situation and needs and dive into what they already knew about their own needs, filling them in on what they need to know before making a decision to go forward, and how we'd go about ensuring that we meet their expectations.

Herein lies perhaps one of the keys (if not the crux) to helping CMMI and other process-types along in their ability to understand Agile, and implement process disciplines that can also be Agile. The focus must be on the customer's needs.

So many of our CMMI colleagues (often called "competitors") focus on the implementation of the CMMI as the goal, when really, it's not. What *is* the goal is helping *our* clients meet *their* business needs, and by doing that we are focusing our efforts on the right things and on things that help our clients make (or save) money.

Looking beyond the commonly-held value-proposition that process improvement has its own ROI, if we as an industry ever want to be able to make positive inroads towards the "agilization" of CMMI and other process disciplines, we must make the paradigm shift towards the customer's *business* needs, and not just their prima facia stated goals of "achieving CMMI 'level' X".

Keys to Enabling CMMI

What's CMMI all about?

Well, instead of getting into CMMI itself, let's look at what CMMI is really doing.

CMMI has a:
1) Purpose
2) Method
3) Mode/Means

Purpose
The Purpose of CMMI is to improve processes to facilitate organizations' abilities to deliver product on time (schedule), within budget (cost) and that does what it's supposed to do (quality/functionality).

The authors of the CMMI found a set of practices that, when performed, has a consistently positive effect on Schedule, Cost and Quality/Functionality. Furthermore, they found that these values can be further improved and optimized by being able to pinpoint controllable variables and apply quantitative analysis on those variables to tweak what affects them.

Method
The Method CMMI uses is one of graduated institutionalization. The graduated approach towards institutionalizing processes starts with simply performing process improvement practices without much by way of managing and organization. The next step moves up into planning and providing resources, training, and controlling the output and checking the results of the processes. After that, further institutionalization includes creating consistent practices across projects, collecting feedback about the processes then finally graduating towards statistical controls, predictive analysis and removing causes of inconsistencies.

Mode/Means
If nothing else, an unspoken theme throughout CMMI is that of Communication.
How *any* of the practices work is that they facilitate communication because they require communication in order to work and won't work without it. However, communication isn't just project participants talking to one another. Communication also includes communication for the benefit of those from whom we need some action to be taken as well as for the benefit of those that follow us.

In other words, it's not just organizational (vertical and horizontal) communication, it's also temporal communication. In order to effectively bridge the temporal (as well as sometimes the organizational) communication, practices that improve processes need to be conveyed in a manner that withstands situational and temporary circumstances.

Situational and Temporary circumstances are a fancy way of pointing out that relying on individuals to pass project legacy and lore from person to person will quickly break down under the pressure and influence of time, environments, and personalities. Artifacts (not necessarily 'documentation') are how we bridge the temporal communication issue while also benefiting the organizational challenges in communicating what we need, what we did, what we're doing, and the 'why' of it all.

While the need to communicate face-to-face is essential in every successful project, it can't be the only way we communicate on longer-term projects or across distances. Neither can it be the only means of communication even on short projects where the product outlasts the development organization by many times over. There are many ways to create artifacts, some are more time-consuming and less valuable than others, but the need to create them comes from the need to facilitate broad communication that extends beyond simply face-to-face.

Lastly, practices that rely solely on face-to-face communication, without the benefit of some procedures is definitionally an 'ad hoc' process, and, is at the lowest level of institutionalization. This isn't to say that they are ineffective, but simply that they are not institutionalized and therefore are unlikely to persist from project to project. Finding the abstraction for a practice that can both persist from project to project while also being re-structured to meet the differing needs of each project is not only what makes Agile approaches to CMMI possible, but also corresponds directly with what one does when graduating their practices from one level of institutionalization to the next.