I’m not sure, but I’m told some famous guy back in Biblical liturgy was once asked to explain the point of the Pentateuch (aka, the Torah, aka, The Five Books of Moses) while "standing on one leg".  

I now undertake a task, possibly no less daunting, regarding CMMI.  And, if there ever were anyone more appropriate to try it, I doubt I’ve met them.

Seriously though, much has been written here and many other places (not to mention eons of conference and user group content) about a number of "universal truths" about CMMI.  Let’s get these out there first, but without dwelling on them:

• There are no "processes" in CMMI, only practices, and there’s a difference.
• The practices in CMMI are "what" but not "how".
• These practices are use to improve your processes, not to define them.
• The CMMI does not require the SCAMPI appraisal to be effective.  You can use CMMI to improve your operation without ever using the SCAMPI to appraise your use of CMMI.
• 42.  OK.  Not really.

However, not a single one of these "truths" explain the point of CMMI, or,  how to actually use CMMI.  So, here it goes:

Each one of the practices in CMMI improves some aspect of your organization’s performance resulting from how you do your work.  It doesn’t matter whether it’s providing a service or developing a product.  And, it doesn’t matter whether you do so using so-called traditional development methods or Agile approaches.  If you have performance issues in an area of your operation (called, "Process Areas" in CMMI), Check each of the practices in that area for activities in your operation that might be causing those performance issues. 

It’s assumed, then, if you don’t have any issues covered by a practice then you don’t need to do anything about a practice, because you’re already doing it.  This says nothing of how well you do it, why you do it, how you do it, whether you recognize that you do it, or whether the fact that you do it is a complete coincidental freak of nature, but, if you read a practice, understand the risk it avoids, and you don’t encounter that risk, you’re somehow performing that practice.  Pretty simple.

I’ll repeat and summarize that two-step thought experiment:

1. Look in the process areas for practices that address performance issues you’re experiencing with the operation of your work.  When you encounter a practice (or more than one), the absence of which can explain why you’re seeing those issues, make appropriate changes to your operation so that you incorporate that/those practice(s) into your operation.  Rinse and repeat.
2. Practices that don’t represent risks or issues you’re not seeing are (pretty much, by definition) practices you’re somehow managing to accomplish.  Don’t bother with them — unless you notice that you don’t like something about how you do it, but that’s a different priority/matter.

Keep in mind, this says nothing of

• whether what you do/don’t do will suffice as "evidence" for an appraisal
• how well you perform the practices (regardless of whether or not you perform them or believe you can use them to improve),
• what it takes to incorporate practices or make change, in general, happen in your operation,
• whether an appraisal team will concur with whether you do/don’t perform practices, or
• you interpret practices in constructive ways.

Nonetheless, if you internalize the significance of the above 2 steps, you can (I dare say, "will") save yourselves a lot of time and grief when using CMMI.  This approach can certainly help you prioritize the practices for which to focus on, appraisal or not.  And, if you do take this approach towards preparation for an appraisal, keep in mind the bulleted caveats and don’t try this alone.

OK, OK, so it’s Mothers’ Day in the US… but we all miss out on family matters all the time for things far less awesome than this.

Lean Camp New England is a one day open space event led by Jim Benson, author of Personal Kanban. It is an opportunity to share and learn about Lean and Kanban in software development, IT operations and services, and other knowledge work fields.

Lean Camp New England is an all day event at the World Trade Center Boston, on May 13th (Sunday).
Registration is open now at a cost of $300 – catering is included.
Register at http://lssc12.leanssc.org/.

Boston is the center of gravity for lean thinking in the US. However, much of that thinking has been in fields outside of IT and Software and Systems Engineering/Development.

If you live in New England, or people you know live in New England, and are interested in getting up-to-speed among the leading thinkers and practitioners in Lean in IT and Software and Systems Engineering/Development, I highly encourage you and them to register for Lean Camp New England.

This is a rare opportunity to enjoy a regional 1-day open space / unconference in conjunction with a large international conference, Lean Software & Systems 2012 – as a result a significant number of international experts will be present and participating.

Where else can you get direct coaching from the experts for only $300?

Want fast, easy CMMI ratings?  Even high maturity?

First, implement lean, Goldratt’s TOC, Deming’s ideas, Kanban, and other related concepts, then get busy with CMMI.

What you may not know is that lean is easier, faster, and generates better performance results sooner than CMMI.

Lean improves delivery issues sooner than process improvement alone.  Improved deliveries improves revenues, stabilizes cash flow, increases margin, makes customers happier and results in more sales.

In other words, lean means better flow and better flow means better business.

CMMI is great, but is often attempted as a first line of offense to issues it’s not meant to deal with.  CMMI is meant to improve flow, not define it, and, lean helps define flow.
(Yes, I know I said "theory of constraints" twice.)

Assuming there are unfulfilled orders in the sales pipeline, lack of revenue is due to lack of flow.  Typically, this is due more to what’s in the flow, how much is in it, and the clarity and cleanliness of how the operation’s flow is aligned.  Using CMMI to "fix" issues with flow is like using the Brownian motion of steeping tea to power a random-number generator.  It’s just too much too soon.  Process issues are themselves symptoms of flow issues.

Deal with the symptoms first.  Then, tackle the processes.

Two events to put on your radar:

Lean Software and Systems Conference: Boston, 13-18 May (Lean Camp & Lean Action Kitchen, Sunday, Conference Monday-Wednesday, and Tutorials Thursday & Friday).  I’m helping to organize and speaking at the conference, and running a tutorial on this topic on Thursday.

Kanban Change Agent Masterclass: Miami, 23-25 May.  I’ll be participating as a special guest to demonstrate how Kanban helps achieve CMMI ratings, including High Maturity.

Apple, Inc. learned the hard way what happens when engineering isn’t complete.  In particular, when verification and/or validation aren’t performed thoroughly.

Verification is ensuring that what you’re up to meets requirements.  “ON PAPER.”  BEFORE you commit to making the product.  It’s that part where you do some analysis to figure out whether what you think will work, will actually do what you expect it to do.  Such as, walking through an algorithm or an equation by hand to make sure the logic is right or that the math is right.  Or, stepping through some code to see what’s going on before you assume that it is behaving.  Just because something you built passes tests, doesn’t mean it is verified.  All passing tests means is just that: you passed tests.  Passing tests assumes the tests are correct.  If you’re going to rely on tests, then the tests need to be verified if you’re not going to verify the requirements or the design, etc.  Another problem with tests is that too many organizations only test at the end.  Verification looks a lot more like incremental testing.  Hey wait!  Where’ve we seen that sort of stuff before?

Had Apple’s verification efforts been more robust, they would have caught the algorithm error that incorrectly displays the signal strength (a.k.a., “number of bars”) on the iPhone4.  This is why peer review is so central to most verification steps.  The purpose of peer review, and of verification, is to catch defective thinking.  OK, that’s a bit crude and rude… it’s not that people’s thinking is defective, per se, but that thinking alone didn’t catch everything, which is why we like to have other people looking at our thinking.  Even Albert Einstein submitted his work for peer review.

Validation is ensuring the product will work as intended when placed in the users’ environments.  In other words, it’s as simple as asking, “when real users use our product, how will they use it, and will our product work like we/they expect it to work?”  Sometimes this is not something that can be done on paper, and you need some sort of “real” product, so you build a prototype.  Just as often it’s not something that can be done “for real” because you don’t get an opportunity (yet) to take your product into orbit before it has to go into orbit to work.  Sometimes you only get one shot, and so you do what you can to best approximate the real working environment.  But neither of these extreme conditions can be used by Apple as excuses for not validating whether or not the phone will work as expected while being held by the user to make calls.

Had Apple’s validation been operating on all bars, they likely would have caught this while in the lab.  When sitting in its sterile, padded vice, in some small anechoic chamber, after taking great care to ensure there are no unintended signals and nothing metallic touching the case, someone might’ve noticed, “gee, do you think our users might actually make calls this way?”  And, instead of responding, “that’s not what we’re testing here”, someone might’ve stepped up and said, “hey, does our test plan have anything in it where we’re running this test while someone’s actually using the phone?”

Again, testing isn’t enough.  Why not!?  After all, isn’t putting it in a lab with or without someone holding the phone a test?   True…  However, I go back to the same issue we saw when using testing as the primary means of performing verification… Testing is too often at the end.  Validating at the end is too late.  You need to validate along the way.  In fact, it’s entirely possible that Apple *did* do validation “tests” of the case separately from the complete system, and, in *those* tests — where the case/antenna were mere components being tested in the lab — performed fine, and, then only when the unit was assembled and tested as a complete system would the issue have been found.  In such a scenario we learn that component (elsewhere known as “unit testing”) is not enough.  We also need system testing (in the lab) and user testing (in real life).  Back we go to iterative and incremental…

So you see… we have a lot we can apply from ordinary engineering, from agile, and from performance improvement.  Not only does this… uh… validate(?) that “agile” and “CMMI” can work together but that for some situations, others can learn from applying both.

In full disclosure, as a new owner of an iPhone 4, I am very pleased with the device.  I can really see why people love it and become devotees of Apple’s products.  Honestly, it kicks the snot out of my prior “smart” phone in every measurable and qualitative way.  And, just so I’m not leaving anything out, the two devices are pretty much equally balanced in functionality (web, email, social, wifi, etc.)  – even with the strange behaviors that are promised to be fixed.  For a few years, this iPhone will rule the market and I’ll be happy to use it.

Besides embarrassing, this will be an expensive couple of engineering oversights for Apple to fix.  And, they were entirely avoidable for an up-front investment in engineering at an infinitesimal fraction of the cost/time it will take to fix.  For even less than one day of their engineering and deployment team’s salary, AgileCMMI can make this never happen again.

Apple, look me up.  I’m easy to find.

Sorry, folks, no fun (or not-so-fun as you may prefer) video today.  Not even any pictures I took at SEPG.  In fact, as far as today went, I don’t have much to report from the sessions.

Again, I missed the plenary session.  This time on account of a phone meeting with a client in another time zone.  So, my first session to attend was the other of my two collaborative efforts with Judah Mogilensky on SCAMPI Evidence from Agile Projects. As anything with Judah in it, it went rather nicely.  Many generous bits of feedback.  I felt really good about my role, and Judah was his usual incomparable self.

My friend and colleague, Eileen Forrester of the SEI was kind enough to give me some supremely powerful feedback.  I am, and will be, grateful for it.  I was then roped into shop talk about CMMI for Services in advance of the 2nd half of the orientation workshop I’m helping her with.  Thus, my missing out on my buddy, Jeff Dalton’s, excellent (so I’m told from many reports) job with Encapsulated Process Objects.

One point made to me later by another of the few “agile-friendly” lead appraisers, Neil Potter, about a bit of content in the presentation does require some follow-up.  In the presentation we short-cutted the details on a discussion regarding the potential design aspects of test-driven development with an engineering design.  I should say that TDD is NOT the same as a design, but that depending on how TDD is planned and performed, it can include design-like attributes which could accomplish design expectations in the engineering process areas of CMMI-DEV.  So don’t anyone out there go around blabbing some “Hillel said TDD is Design!” crap.  Mm’K?

After lunch, my job was to keep people from falling asleep with a session on Love and Marriage: CMMI and Agile Need Each Other.  From the response, I think it went went rather well.  I, personally, was quite pleased with how it came off from a “talk per slide” metric.  A good friend, Tami Zemel, later admitted that she “takes back” her earlier criticism of Monday’s presentation.  She said it had too many words and didn’t believe me when I told her why.  She complemented not only the picture-centricity of today’s pitch but also the delivery, style, and content.  That was very generous, thank you.

From then to the end of the day, I spent scheming, strategizing, shmoozing, and networking with too many people to mention.  (No offense.)  A client who came to the conference (who never holds back and only inflates the truth when it’s funny to do so) got very serious when a prospect I’d recently met off-the-cuff asked whether he’d recommend me.  I won’t repeat his answer because it really was just crazy nice.  Today’s interesting photo is in his honor.  (And also because my boys love transportation.)

The last “session” was a Peer 2 Peer double-header on the topic I mentioned on Monday which I co-created with Michele Moss.  She and I are also on the SEPG Conference Program Committee.  We used the feedback and other data from the Peer 2 Peer as input to a retrospective on this year’s conference, which will be used for strategies for next year’s conference in Portland, OR.

You can also read an entry I gave to the SEI for their official blog about my impressions of this year’s conference-goers.

Dinner conversation back at the hotel with Michele was back on the subject of our Peer 2 Peer session.  Net result: We single-handedly wrote the 1-3-5 year plan for all SEPG’s.  Or at least we think so. 

An article in this month’s CrossTalk periodical, is now out.

See it here.

Download it here .

Enjoy!

P.S.  There are other great articles in the issue as well.  I’m in great company with an article by my friend, colleague and client, Jeff Dutton.  And, don’t miss out what’s coming next in v1.3 from my buds Mike Philips and Sandy Schrum!

I’ve created this (goofy?) promo at the request of the organizers for the 5th Central and Eastern European Software Engineering Conference in Russia.  It takes place the last week in October in Moscow.  I’ll be delivering a keynote and a workshop on AgileCMMI (of course, what else?).  In particular I’ll be pimping my idea that CMMI and Agile *need* each other.

As noted, the Webinar with the SEI will be on the same topic.  So far, nearly 400 people have signed up for that!  The direct registration link is: https://www1.gotomeeting.com/register/167857128.

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.

A recent post to the Agile Thoughts blog caused me to have a serious case of déjà vu. 

First, I will start by saying that I’m not going to take a position on the content of the post.  Namely, I’m not going to weigh in on whether or not Scrum is valid, whether or not Mary Poppendieck’s points or approach are appropriate.

The purpose of this post is to make a suggestion.

Go ahead and (re)read that post. 

Replace

• "Scrum" with "CMMI",
• "CSM" or "Scrum Master" with "Lead Appraiser", and
• "Lean" with "Agile". 

My favorite line in the entire post is this one:

"… spent 90% of her time cleaning up after bad Scrum implementations…"

And an associated comment that noted:

"…the difference between the good and the bad ones depends mainly on who’s doing it…"

I don’t feel like taking the time right now to ponder what it means (I’ll probably do it anyway after posting), but what I find fascinating is that people are now debating various agile/lean concepts in the way the debate continues to fester about CMMI/agile.  And, those in the agile/lean debate are recognizing that it’s not enough to have a named method or model, and it’s not enough to be "certified" to do something to really "get it", but that there is real need for understanding the underlying concepts and intentions and for implementing from that basis otherwise there is risk of "bad implementations".

What every perspective in these discussions is (hopefully) saying is that there is no one "silver bullet".  That addressing the issue of great products, ecstatic customers and happy teams requires more than superficial application of someone else’s ideas.  Requires more than one set of principles, when hiring an "expert" requires serious due diligence and interviewing skills, and requires a lot of hard work and soul-searching to reach the "comfort zone" of every project and team.

Again, I’m not pointing fingers and I don’t want to accuse one person of saying something they’re not, nor do I want to label an entire field of people with any one person’s perspective.  With that said, the following is drawn from my own experience and I’m merely reminded of it thanks to Tobias Mayer’s post.

Many people now finding themselves defending Scrum — against bad implementations and other abuses — are saying that it’s not anything inherent in Scrum that’s bad.  My guess is that many of these people are (or were) also among those who vilify (vilified?) CMMI.  Accusing CMMI of evils that were perpetrated by too many goobers inappropriately implementing and appraising it.  Vilifying CMMI (can be read: Scrum) by juxtaposing implementation with content.  These evils are just as much not CMMI’s "fault" as bad Scrum implementations are Scrum’s "fault".

In fact, our recent SEI Technical Note, spoke to this very issue.  I guess the point to this post is to say to those folks in the Scrum and Lean communities: Welcome Aboard!  Let’s start some constructive discussion together on defeating "silver-bullet-ism" in software development.