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.

Reintroducing "engineering" to software.

I've been noticing an interesting "convergence" going on in this corner of the universe:  "engineering" is being re-introduced to the idea of software.  It's fascinating how no sooner do I have the idea to write this blog (while entirely not connected to the Internet), then I re-connected to get an article that's entirely speaking of the same root issue.

Of course, I'm not saying that engineering had completely left the software universe, though, a strong argument can be made that for the last decade and then some, software has allowed engineering to escape from the premises.  In particular, architecture, analysis, systems thinking, design, hardware and other integration issues, and planned, deliberate, methodical testing have largely been allowed to merely "emerge" from the work that was completed.

Again, I'm not advocating for Big ____ Up-Front as a solution, what I'm pointing out is that many people who embrace agile methods incorporate engineering practices into how they organize and perform their work, but enough don't that it raises issues with agile scalability.

And here's where I *am* expecting to annoy some people...

Programming and Development are NOT the same.

Development is an engineering function.  Developers ought to be using engineering practices in what they do.  Just look at the word "development".  The connotation is that something is "grown" or "evolved".  The denotation of 'development' in the technical sense is that it is done deliberately, not by happenstance.

This idea is where I believe software, in general, not limited to agile practices have short-changed themselves.  Too often, activities that amount to nothing more than programming are called development when no actual engineering is happening.  In other words, programming is allowed to take place without any (or at best without enough) engineering, and therefore what's really happening is the building of something without any/enough forethought about the thing itself that is to be built.  Instead, what happens too often is all the focus is on "staying busy" (albeit on ostensibly priority work), but what is worked on is absent sufficient technical rhyme or reason.

Is this true of all agile development?  NO.  But, it is what happens in many organizations when they don't have sufficient technical leadership.  For what it's worth, many development projects don't need much engineering, and product development is sufficiently described in tasks defined by few people.  So the jump from development to programming is small and fast. 

However, there are projects (or tasks) of sufficient technical complexity that skipping the engineering and handling such projects/tasks as programming alone is where I believe a space is created for the unfair reputation for agile and its scalability, as well as some of the anti-process bias among agile proponents.  When I read (and sometimes contribute) to agile and non-agile software groups, I'm often struck by the same thought: where's this person coming from?  This is basic engineering!

But that's the matter, isn't it?  Programming isn't development without engineering and too many programmers aren't engineers (not should they be) but are being told to "develop" without given the time or resources or something to do the engineering.  And so what they're really being told to do is "program", not "develop".  Someone, somewhere doesn't see and/or understand that what many projects need are to be engineered.

I think what this points to is a persistent phenomenon plaguing software: it's not being taken seriously as an engineering discipline.  Sometimes by leadership in organizations where software is being worked on, sometimes by programmers and sometimes by customers.  I'm sure there's plenty of blame to spread around, and spreading the blame is both a waste of time and not the point at all.

Programming is to software as assembly is to construction.  Not everyone swinging the hammer needs to be the civil engineer nor the architect, and not everyone with a nail gun can be the foreman (and no, I'm not likening the skill set of programmers to those of construction workers, and no, I'm not saying construction workers aren't smart....geez).  There has to have been engineering taking place before software can be actually developed, and as evinced by the kinds of challenges I encounter regularly, enough software shops are going about their work absent acknowledgement or awareness or consideration for the engineering that has taken place or has yet to take place (or should have taken place but didn't[!]).

Process stuff generally finds its roots in engineering.  Especially process stuff as found in CMMI for Development.  Excepting processes that are over-engineered, are themselves lacking in engineering, or are odious even alone in a room, I'm beginning to piece together that resistance to processes in general, and CMMI in particular, is actually from a lack of engineering discipline in the software practice and not from anything intrinsic to process as a topic.

It's no wonder CMMI is so hard to use by so many, it assumes people are not only experts in process improvement, it also assumes everyone using it is an engineer.  Some people are nail-gun swingers, worried about getting enough done that day to avoid having to work on the weekend.  Meanwhile, someone else already worried about in what order to build piece the trusses together and someone before that worried about the right number of trusses and their thickness and someone before that worried about its shape.

It's becoming fairly clear that anyone fooling themselves into believing that agile advocates not doing an architecture at all, or a design at all, or other engineering activities at all are doing themselves a disservice.  In fact, I'd go so far as to say that once an architecture has been settled upon and once a design becomes clear, that agile practices can happen more freely and effectively.  More so, I'd assert that the future of agile "scalability" depends on these.

What I and a colleague are setting out to do over the next few months is help agile scale by re-introducing engineering to software, and while we can't fix the software universe, we hope to help agile out by giving it some engineering practices that software (as a whole) lacks -- not everywhere, just in too many corners -- but that we believe agile can really take and run with.

Let me know if you want to play with us.

Field notes from SEPG-NA 2009 - Thursday

San Jase, CA.  Actually there won't, unfortunately, be much to report today as I was side-tracked from all but one session.  The session I attended was an experience report from a lead appraiser working with a company whose total size was all of 12 individuals.  In fact, they were a distributed workforce with no central offices.  Everyone worked from home.  This was a report on how they achieved CMMI ML3.  The company itself had very impressive results made possible by very impressive people and attitudes.  Let's get one (or two) things straight immediately: (1) they really truly were ML3, no corners cut, they really truly did the work of defining, managing and using their processes, (2) they did NOT need CMMI to be disciplined -- to a person they were highly skilled, highly technical, supremely professional, absolutely committed their work and company, incredibly laid-back, and deadly serious about NOT causing themselves work that was not fun and benefit the work and company.

The moral of this story is that the primary driver of improvement (of any flavor) is first and foremost attitude and culture.

Moving on.  I stopped by David Anderson's last talk of the conference on Metrics and Agile, and once again, it was close-the-doors-room-is-full SRO.  While other sessions were letting out early and people were streaming out right at the stop time (time for lunch!), David's session was full until kicked out.  Once again, put CMMI, Agile, and Maturity in the same space and sparks fly.  Dave impressed several very important people.

That's all I have to report today about the conference.  Stay tuned for SEPG-NA 2010.  I'm contributing to the program committee and know there are some really great things in store.  Planning for it started today and I've got action items due.  :-)

Field notes from SEPG-NA 2009 - Wednesday

San Jose, CA.  Behold: Alistair Cockburn.  At the end of SEPG-Europe 2008, I was in a conversation with SEPG program chair, Dr. Caroline Graettinger.  We were discussing the theme of the 2009 series of SEPG conferences on Next Generation of process.  I immediately thought of and fired off an email to Alistair.  Intrigued, he said that he's working on a very similar sounding set of ideas calling them, Software Development in the 21st Century, and accepted shortly thereafter.

This ideas are based in metaphors to help really manage software development the way software is really developed.  Cooperative Games, Craft, and Lean.  The details of this talk are on Alistair's web site.

Alistair was poignant (despite mentioning me by name) and funny and fielded questions from the audience.  Kudos my friend.

Another Jim as Sr. Director for Software Quality, Jim Sartain, currently at Adobe, came next.  Previously at Intuit and before then HP.  Leading with the fact that TSP goes where he goes.  (See more later.)  He showed the same slide from yesterday's Intuit presentation showing "most admired companies" where Intuit is #1 and Adobe is #2.

ANOTHER "quality" person with a REAL personality!  A clean-sweep for great SEPG speakers!  Too bad the economy kept more people from experiencing them!

Jim spoke about giving engineers the tools and work-life balance that can double their productivity and morale. Note: research this when there's time.  And while I'm at it, research why it's the commercial companies of the world who truly embrace quality culture and the government-oriented ones don't.  (Never mind, that's rhetorical.)

Wanna "get" how serious they are?  They frakking flew Watts Humphrey in to San Jose to launch TSP and brought as many engineers from around the world in to hear it.  But since their operations in India are so significant, they did it again in India!

Their results with TSP are beyond quality improvements, but work-life balance, team commitment, team self-direction, senior leadership buy-in (removing obstacles).  TSP provided a means of measuring the effort and using that data to negotiate better expectations.  (Both Alistair and Jim noted the importance of metrics to transparency and improvement.)  Jim also took questions including why to wrap TSP in Scrum.  Reasons: (1) Product owner, and (2) defined "done" at each iteration.  It turns out that TSP came to Adobe, not because of Jim bringing it rather because people at Adobe heard the great TSP stories coming from Intuit and "want sum'dat!"

A first for SEPG, was the inclusion of time between the morning's keynotes and lunch for very user-group-esque "peer to peer" sessions.  Conference participants self-selected into table-top discussions driven by other attendees, not selected by the conference program.  In fact, attendees put up topics and volunteered to lead them -- or put up topics in hopes of someone else showing up to lead and play subject-matter-expert.  To no-one's surprise, David Anderson signed up for agile and lean discussions.  (David's in the ruddy color left of center in the image.)  And, again, to no-one's surprise, there were more people interested in this topic than room at any one table, so the conference logisticians moved the crowd to its own room where, as can be seen in the photo, numbered several dozen people.  Subsequent to this image, more arrived and were standing around the seated area.  One might sense a trend of growing interest in this population for the last few years whenever the terms "CMMI" and "Agile" are put together, eh?  As it turns out, of the several simultaneous peer-to-peer sessions, the two with the most participants were the Agile-related one and the TSP one.

(Well, super insider's double-hush secret preview scoop of things to come: expect Agile, Lean, and TSP to start showing more prominently both at SEPG and throughout the work being done at SEI.)

David lead Achieving High Maturity with Kanban mini-tutorial.  His talk was mostly about the culture necessary to achieve high maturity and how Kanban can facilitate it that.  But describing it that way makes it sound like it was a commercial for Kanban.  It wasn't.  It was about culture's and measurement's roles in maturity of development, productivity, quality and production management.  How the data drives the actions of the teams and these actions can be demonstrably linked to things that can actually be managed.  One way to summarize is in how he said, that "level 5" results are achievable by setting expectations of level 5 behavior as a matter of culture.  It's telling that David's session spanned 2 normal sessions.  People had the opportunity to leave mid-way and go to other sessions.  Despite other session opportunities, there was a net gain of attendees in David's session.

After that, came me.

The CMMI Guide to the Perplexed.

Well-attended, many friendly faces and most people seemed to enjoy it.  Lots of positive feedback... of course, detractors seldom tell you to your face, do they!  You can get the presentation here.

Field notes from SEPG-NA 2009 - Tuesday

San Jose, CA. Day started (for me) @ 4:45am PDT (which my body believed to be 7:45am) with a work out, some email and chat, quick breakfast, and a teleconference with a prospective client. I arrived to the conference hall just as Dr. Paul Nielsen, CEO of SEI was introducing the first keynote, Scott Cook co-founder of Intuit Inc. (now chairman of the company's Executive Committee of the Board).

Impressive start-up story, but more impressive is their use and integration of TSP and Agile (Scrum).

He also told the old story about Chevrolet and Toyota in which Toyota ran a Chevrolet factory in this area using their production system keeping Chevrolet's UAW employees. Resulting in turning the worst plant in the company into the best Chevy plant in the entire company. Anyway, he probably spent too much time on that story. Unfortunately, too many people in these circles aren't professionals in process improvement to know that story -- which is now part of the process improvement lore.

Though he summarized TPS in an interesting way, saying that it's a process for rapid experimentation. I can see how he'd come to that conclusion considering the emphasis with TPS on Kaizen. He also spoke about the lack of process improvement in businesses who would desperately need it, like hospitals today in the USA. (I should note that UPMC is an exception in leading the way. Get with it everyone else!)

Jim Bampos, VP of Quality at EMC spoke as the next keynote. Turns out he was a toy tester for Milton Bradley when he was in kindergarten. Spoke about leveraging processes and process improvement to facilitate their Total Customer Experience ("TCE") program. The way I'd say the same thing — to my clients, not to correct Jim — is that it's necessary to connect process effort to business values and goals. Nice. Jim was up-front that they have no interest in CMMI appraisals, and he didn't know the CMMI appraisal lingo, which made the sincerity of their effort that much more obvious. He mentioned that after several months of process improvement effort and measurement, that despite having great data, it still didn't connect to their "TCE". Very poignant!

Very refreshing keynote in that he was brutally honest about quality and findings of their investigation into what drives customer experience and loyalty. They take process so seriously that they tie improvement to metrics, goals and bonuses.... FROM THE CEO on down! NOT process compliance or some crap like that, but their actual demonstrable process performance measures tied to money as a function of whether it supports their corporate goals — which are laser-focused on customer experience. EMC is looking to implement all three CMMI constellations. For good measure, he spoke about the fact that they're using agile practices all over the place.

Who's "pushing" them to do all this? NO ONE OTHER than themselves. Almost makes me want to work there. Almost.

In all, really great keynotes. Each SEPG conference should be so lucky.

Next up: CMMI or Agile: Why Not Embrace Both! Being led by Mike Konrad. Jeff Dalton, David and I joined Mike on stage. We stood because there weren't enough seats for the audience and the union wouldn't allow us to bring any more seats into the room due to capacity concerns. (In fact, a guy stood outside the room to prevent people from coming in. One such person blocked out was Alistair Cockburn, whom I went out to drag in despite the protests of the bouncer dude.) Mike reprised a presentation he'd done elsewhere summarizing the main points of our paper and adding some new material making a case for process discipline in a couple of engineering-related process areas of interest. The slide, here, is an idea David and I intend to "borrow" from, depicting, manifesto style, concepts we value from CMMI compared to other concepts possible from CMMI we value less.

Last for me for the day was an interesting perspective on CMMI and Innovation. Presenters' positions are that CMM started as something that would help organizations take revolutionary steps in innovative improvements as well as evolutionary steps and that while the model still can support this, use of the model has been far from it. In addition, they discussed innovation as a process and then how CMMI could be enhanced, supplemented, or even "constellationed" into being more proactively in support of innovation. The speakers were very passionate about innovation. Props for that. Need more of it. They also posited that "maturity levels" for organizations using such a model would be superfluous and that what would matter most to anyone pursuing innovation would be business results. While I wholeheartedly endorse the idea of innovation as a pursuit to which processes can be applied, I was left wondering why *must* it be a CMMI? Maybe I'll be able to tag-up with one of the presenters to ask before week's out.

Field notes from SEPG-NA 2009 - Monday

San Jose, CA.  I'm at (no surprise) SEI's annual big deal conference, SEPG-NA.  As might be expected, attendance is way down due to the economy.  SEI had to scale back a lot of the more splashy touches -- no-frills tote bag, nixed VIP socials mixers bare bones staff.

I arrived in time to teach a CMMI-SVC Supplement course for the SEI on Sunday -- scheduled to coincide with SEPG for the convenience of travel -- that evening I shared conversation and a bottle of really nice California Merlot with Alistair Cockburn, Tami Zemel and Steve Masters.  Earlier in the day Alistair listened in on my class from the corridor and over cheese and fruit bluntly reported that the content made his ears bleed.  Unfortunately, he's right.  Despite the mostly very positive feedback, there's only so much charisma can do for certain SEI materials.

Alistair challenged me to explain CMMI to him in 5 minutes or less or he'd fall asleep.  I believe I succeeded.  He Tweeted as much at least.  As it turns out, not to either of our surprise, whether using agile terms or traditional terms, if you're working to improve the experience and situation of "development", you have the same goals and face the same challenges.  With that settled we called it a night and met this morning over breakfast to joke about travel anecdotes and strategize our individual plans for the day.

With other obligations on my plate for this week, this morning I only sat in on half of a half-day tutorial this morning on the excellent topic of The Role of Organizational Culture in Process Improvement.  Rather than a bunch of finger-wagging (which, from other presenters, such a topic title might devolve into), anthropologists, Palma Buttles and Fred Valdez, and process improvement uber-guru Judah Mogilensky gave a very well-informed, thoroughly enjoyable, interactive and insightful tutorial on several very specific attributes of culture that affect how to introduce, address and implement process improvement, and the challenges faced by consultants, appraisers and users alike due to culture.  Concepts on the perception of time, surface or hidden emotion/expression, stated vs. rewarded values, and so on.  During this session, David Anderson arrived.  We commiserated over the registration statistics and what it may imply for other large-scale conferences like Agile2009.

To round-out the day's sessions I attended Corey Ladas' mini-tutorial, Launching a Kanban System for Software Engineering.  He put up a slide depicting a "waterfall" life cycle which included a "stabilization" phase-gate to which he said, "I don't think I'm saying anything anyone doesn't already know will fail."  Someone in the audience stopped him to ask (with incredulous tone in her voice), "Are you trying to say that this approach doesn't work?"  <<Snicker.>>

After the tutorial, I headed off to the exhibit area for the "grand opening" of the exhibit hall.  As part of the fanfare, a troupe was hired to march around the exhibit hall in oriental dragon costumes accompanied by drums and cymbals.  It was festive and lively.  Though it would have been more appropriate had they been asked to start things off, lead everyone into the hall, do a circuit around the hall, then be done.  Instead, they continued to perform for a lot longer than needed.  In addition to causing traffic problems (which wasn't really a huge issue), they made it hard to speak while nearby.  That was an oversight.  After a break, they returned to continue, only playing softer.  Still, their initial display was too long and they didn't have to come back.  It wasn't that it was bad, it was merely unnecessary.  As for the exhibit hall... so sad... so many fewer, and each booth featured fewer people.  The student posters, were a refreshing new feature this year.  I was impressed with their efforts, both in terms of research and commitment.  First person I ran into was from, of all places, UMBC.  Yup, home turf.

Afterwards, David Anderson and his gf joined several of us for a wind-down at the Marriott's concierge lounge.  Well, as I should expect, my increased visibility within SEI and within the CMMI-oriented market has also resulted in never having to sit alone if I didn't want to.  Even then, I didn't always succeed in getting long stretches of time on my own.