A starting point for a discussion on marrying Agile methods and CMMI.
20Jun

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.

13Jun

Prague Report: SEPG-Europe 2009


Despite half the attendance from 2008, the sessions were of very high imagequality 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.

image 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 networkinClock tower after dusk ~9pmg 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.

4May

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.image

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. 

image 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 image 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 peopleimage 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.

Copyright Agile CMMI Blog

CMMI, and SCAMPI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

WordPress Theme by: Wood Street, Inc.

Facebook Twitter