Top 10 Clues You're Not Ready for a SCAMPI

10. Four months ago you couldn't spell "CMMI".

9. No one in your organization has ever had any training of any kind whatsoever in CMMI, appraisal planning, or process improvement.

8. You haven't worked with anyone (in-house or hired) who knows what they're doing with CMMI.

7. Price-shopping for lead appraisers seems like a good idea. Kind-a like price shopping for a heart-surgeon.

6. After months of work, you switch from one constellation to another and think your appraisal is still on schedule (see #9 and #8). Kind-a like switching your team from field hockey to ice hockey mid-season.

5. Your CEO is petulant about the delay of your appraisal yet has no idea that your actual process performance is in the toilet.

4. You've waited until it's time to start planning for your SCAMPI to start looking for a consultant to help you implement CMMI in an "agile" way.

3. The only people you're sending to Introduction to CMMI are the ones you plan to have on the appraisal. You have no back-up plan if they can't make it to training and/or to the appraisal. Class isn't for another month, and, they're the same ones who've been working on your processes for the past several months, but until now, see #9 and #8.

2. You haven't qualified the people in #3 with your lead appraiser (which you haven't hired yet + see #9 and #8), you haven't qualified the projects to be appraised with your lead appraiser (which you haven't hired yet + see #9 and #8), and nonetheless, you have established a level of effort for the appraisal despite all of the above.

And,

The Number One Clue You're NOT Ready for a SCAMPI:

1. After months of work, you still don't see there's a fundamental flaw in committing to or expecting others to commit to (including your appraiser no less!) a firm-fixed price contract without knowing the requirements.

I wish the above list of clues were tongue-in-cheek.

Sadly, it's not. There is, nonetheless, plenty of fiction in it:

• The order of the list is mostly arbitrary.
  
• The list is not scientific.
  
• The list really should be longer. A lot longer.
  
• These clues are just from my experience alone, and doesn't account for anyone else's, so it's pretty idiosyncratic.

While in many cases, any one of the items in the list of clues could easily sabotage an organization's process improvement effort (let alone an appraisal), one thing that makes it especially troubling is the preponderance with which I encounter a single organization exhibiting most or all of these clues! And yet, such organizations think they actually can dictate to their lead appraiser the terms and conditions and the readiness of their organization to be appraised!

I tried to limit the clues to only things you could pick-up from a conversation -- even if you know nothing about CMMI or the SCAMPI appraisal method. I tried to keep the clues to things that don't have to do with CMMI itself or process stuff as a general theory. If I had included such items, I would add:

• You don't know that to do a SCAMPI you actually have to have used the processes on actual projects.
  
• You don't realize that there's more to CMMI than the names of the process areas.
  
• You don't realize that the generic goals and practices aren't just "extra information".
  
• You don't know that it's still the lead appraiser's responsibility to approve the people and the projects to be in the appraisal.

If you look at some of the other behaviors of organizations not really ready for a SCAMPI, you'll find that they continue to:

• accept more work than they can handle,
  
• be unpredictable in what they will deliver and when,
  
• measure little other than billable hours, and
  
• have no insight into where their defects come from.
  

Despite the condition in which many organizations may have artifacts for an appraisal, they have seen no intrinsic benefits to their new set of processes. They've been just "chasing a level", which results in lots of work for no real benefit. You can guarantee these organizations will drop their processes shortly after the appraisal.

Really, what these clues point to is the dreadful lack of realization that first and foremost, process improvement requires the right culture for process excellence. The above list points to a fundamental absence of the culture for process excellence. What people don't realize (especially in the USA), is that process improvement is a total JOKE for companies with the right culture of process excellence. If people want the truly idiot-proof, guaranteed, easy path to just about any CMMI Maturity Level, they would need to go no further than to foster a culture of process excellence, then whatever they did from that point forward would likely cause just about every practice in CMMI to form on its own. In other words, these clues aren't about process, they're about culture and leadership. You don't have to know anything about CMMI to pick up clues about culture and leadership.

One of the failures of CMMI is that it fails to press the basic importance of culture and leadership for process improvement. It fails to communicate in no uncertain terms that an absence of the right culture (and what that looks like) and the absence of leadership (and how that shows up) will lead to a failure in process improvement -- CMMI or otherwise. I'm not blaming CMMI for not including this information in the text, because much of it is there. What I'm saying is that despite what is there about the importance of culture and leadership, most CMMI users fail to grasp these important points. The text, therefore, fails to communicate this in a way that people will pay attention.

CMMI should come with a warning similar to, "Don't Try This At Home!" or "Use Only as Directed!", or "Check with a Qualified Professional Before Beginning Any Process Improvement Program", or "You Must Be *This* Tall to Use this Book". Or simply, "Danger Ahead!". Something to get people's attention and direct them to some of the fundamentals of any improvement program.

This accusation is not just leveled at garden-variety CMMI adopters. Often, they're the hapless "stuckees" forced to "make CMMI happen" against all odds. At least there's ample reason to be sympathetic to their plight. What's inexcusable are the too-many consultants, instructors and appraisers who are willing to ignore these fundamental requirements-for-success and who are unwilling or unable to posture with prospects and clients in such a way as to impart the importance of culture and leadership to success with CMMI. So, that translates to a pathetic statement about the consulting abilities (and possibly the ethics) of too many people who take money to work with others on CMMI.

Sorry for the rant. But people need to be warned. Attempting a CMMI effort without the requisite culture and leadership attitude may yield a short-term appraisal rating, but will ultimately lead to medium and long-term failure. *THAT* I can guarantee.

This is why I'm such an advocate for agile methods. Agile methods impart some of the basic needs for long-term process success. And, it imparts them at a level of abstraction usable by people who aren't process experts, yet establishes many of the appropriate culture and leadership traits that so many CMMI-only efforts fail to recognize. Agile values, methods, and practices empower their teams, cause leadership to eliminate obstacles, value the input of customers and practitioners alike, values learning, develops multi-disciplined teams, and most importantly (as far as processes are concerned) promotes lean thinking. While Agile ideas may not change leadership and culture over night, they contain many of the right activities that can eventually win over those whose hearts and minds need winning over. And, with the appropriate use of CMMI, agile ideas can kick-start the motion and direction needed for long-term and ongoing improvement.

I'll be writing more about why CMMI and Agile need each other for a while.
Stay tuned.

Prague Report: SEPG-Europe 2009

Despite half the attendance from 2008, the sessions were of very high quality and the size of crowd really facilitated an intimate setting to network, eat more than one meal with old and new friends and to have serious conversations about process improvement and the direction of SEI and its Partner network.

While it's not an entirely fresh thought, it really hit home for me the extent to which conferences -- and other concentrated spans of time, in general -- have the ability to shake loose new ideas. This conference, sometimes (I admit) unlike other events, I really spent an enormous amount of time and energy reflecting on all-things-process including my own work and company, collaborations, CMMI and other SEI products, and the SEI itself at a strategic level.

It's clear that when you spend that much time on learning, studying and inspection of ideas, the constant barrage of collisions and connections, that all sorts of (typically good) things can come of it. Really, I suspect that these not-so-obvious benefits all-too-often go under-appreciated, and under-utilized as secondary and tertiary returns of getting the most from attending conferences and of sending people to conferences. For my time (and money), these events have the potential to be far more value than mere training and seminars. And, this year's, SEPG-Europe really made me appreciate that.

The only event on Monday was a workshop on CMMI for Services which included several spirited discussions about model content and applications. An idea-generating session was conducted for how to address qualifications, continuing education, and related credentialing, for qualifying Partners to teach a new training class I'm helping develop in my role as an SEI Visiting Scientist. This discussion warmed up to even higher heart rates. (In a good way.)

Tuesday was the official tutorials day. My CMMI Crash Course could have gone better -- I was dreadfully under the weather from something I ate the night before. I also had it confirmed for me that the European crowd of novices is very different on many levels than American, British and other cultures. I couldn't get people to participate even with (mock) threats and jokes. They simply wouldn't open up. While they would ask questions at times, if I asked a question, they'd wait for me to answer it -- even when prompted them to answer. It came across as though one Danish student had more courage and better answers than the room full of working professionals.

While having the best of intentions to attend afternoon tutorials, I found myself back in bed, skipping lunch and dinner and only emerging once or twice to grab something to drink to stave off dehydration.

The exhibit area opened Tuesday evening, and I showed up with my shirt hanging out, no jacket or socks and looking very much like someone dragged me outside in the rain, hastily dried me off, then stuffed me into well-worn clothes. But, by the evening I was feeling better. Good enough to go down to the adjacent mall to buy 2 bottles of PowerAde. Once of which didn't even survive to see me emerge back out from the mall.

Wednesday, Thursday and Friday were the main conference days. Each one filled with excellent content. (You can download highlights here.) A former client of mine, Kevin Williams started my Wednesday day off with superb content on his (former) company's CMMI journey complete with metrics, examples, and lessons learned. It was a genuinely rich and rewarding example for how small and agile organizations can stay agile, use CMMI to benefit their work and get a desired rating. Kevin reported that despite having left the company and not having been replaced, the processes put in place under his leadership are still in use.

His session would have been better attended (by more people who really needed the information) had it not been for a slight oversight that left the word "Agile" out of his presentation and abstract. As a result, Kevin's 40-minute slot was opposite the start of a half-day tutorial on agile and CMMI from Tim Kasse who really put agile and CMMI under the engineering microscope -- at least while I sat in on the 2nd half of it, so I assume the earlier half was as hard-hitting.

It was hard to tear myself away from the excellent networking to get back into sessions throughout the week. Then, once I got back inside, there were other obligations keeping me from staying. For example, to go "play expert" for an "Ask the Experts" break-out, I had to bail out half way through Michael West's insightful work and thoughtful mini-tutorial (complete with hands-on exercises) on process design and communication.

The first keynote speakers started Thursday, but afterwards, the highlight of my Thursday sessions was John Hamilton's talk on complex process concepts for absolute beginners. He was highly energetic, entertaining, and very crammed full of excellent advice. I'm "borrowing" several turns of phrase from him -- which is only fair considering he borrowed a number of ideas (and words) from me. Fair trade. (Be flattered, John, I am!) ((John actually asked me about his use of the ideas at his company's recent conference -- where I also spoke.)) I believe it's from John that I tweeted about where the real improvement begins.

Friday. Ah, Friday. The way Friday got started was surely a sign of good tidings. Tony Devlin's keynote was simply inspiring. My tweets (also) from it don't even tell the half of it. Talk about true maturity. Do they *get* this stuff or what?! I can't even bring myself to write about it out of fear of not having time to sleep tonight once I start. I expressed my thanks afterwards and expressed a request for learning from them and extended an open offer to answer questions from my experience in return. He graciously provided me with his email address and said he'd bare all. Then to have had lunch with him was a real treat. I was already eating with 2 SEI personnel (including Mike Philips the program manager for CMMI), and with one open space, Tony asked to join in. After making a fool of myself over light banter -- in which I forgot an actor's name, thereby forgetting his nationality, and only remembering that he portrayed an Irishman in a movie, causing me to think he was Irish, only to be admonished for confusing Irishmen with Scots when someone recalled the actor for me -- we got back to discussing his experience and solidified our intent to exchange information.

Friday was no where nearly done. A session on multi-model collaboration by Kobi Vider-Picker was incredibly well-researched and his audience was full and attentive. He basically laid-out how well the CMMI suite can handle dozens of standards, guides, regulations, etc. I understand he doesn't need to sleep or eat much. It must be how he finds the time between all his work to do such thorough research. The next session was by Malte Foegen, the tweet from that session set off a chain-reaction of re-tweets. Probably my longest ever.

Lastly, my mini-tutorial based on the SEI Technical Note probably had about a third of the entire attendee roster. Of course, by 4pm on Friday, nearly the entire roster had already started out for the airport. By this point, people were more open to volunteering discussion. Nonetheless, I was struck by how deeply ingrained certain ideas about CMMI (and Agile) have been etched. Despite months of promoting the subject since the publication (years prior to that online); despite the availability of the Crash Course, and other sessions from other events, despite all the presentations throughout this and other SEPG events, and for many, having sat through the Crash Course just days before . . . some misperceptions about CMMI and Agile (such as how certain practices "must" be done, or what constitutes "evidence", or that process definition is process "restriction") just are almost too hard to give up.

There is work ahead still.

I'm on it.