Archive for the ‘Process’ Category

Worse than Worthless . . .

Sunday, December 20th, 2009

Your people with prior CMM/CMMI experience are probably worse than worthless, they’ll probably cause you to fail.

Why?

Because what they (or you) think they (or you) know is probably wrong and the advice you’re getting, the expectations being generated are entirely off base.

It all goes back to the many ways in which CMMI can be done poorly and the few, simple, but hard work ways in which it can be done correctly.

Every time I meet with a new prospect I’m confronted with reams of inaccurate assumptions and assertions about what it will take to implement CMMI and how am I expected to “do all that” and still claim to be “agile”.

My simple answer: I’m not going to do all that.  And, you shouldn’t be doing it either.

Seriously, you’ve got to wonder about executives who will force their company into doing stupid things for the sake of a rating instead of doing their homework to learn about CMMI before they head out on an implementation journey.

A recent client didn’t know any better.  They hired a consultant and an appraiser to evaluate their work against CMMI and to help them prepare for a SCAMPI appraisal.  Unfortunately, they got as far as the appraisal only to realize they weren’t going to get the target Maturity Level.  (I won’t get into some of the inappropriate behavior of the firm they hired.)

However, when this client was confronted with:

  1. Do something stupid, or
  2. Find a better way to do something smart.

They took option B and found a consultant and an appraiser who understood their context and found how to both be on a disciplined improvement path while also remaining true to their own business.

Fortunately for them, this client had a strong engineering backbone and knew what they did worked and were confident in their processes.  Many companies have a while before they can claim that much.

Next week:

Picking a Lead Appraiser:  “Dammit, Jim!  I’m a doctor not a bricklayer.”

Prague Report: SEPG-Europe 2009

Saturday, June 13th, 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.

Seat-backs and tray-tables . . .

Thursday, December 18th, 2008

imageA few weeks ago, I blogged about a frustrating incident in an organization created a bureaucratic procedural approach to achieve the desired policy outcome rather than to create a process that would empower the people performing the activity to ensure that the policy was met in the most efficient manner.

That post caused a series of interactions with someone who took issue with my post and assumed the position to defend the procedure I was annoyed with.  I believe we left the matter at a point of agreeing to disagree.

Perhaps this post will cause a different group to take issue with me, but many more people are likely to relate to the content so I can convey the topic of policy-process-procedure in a different way.

A few days ago I found myself in an airline row with 3 seats to myself from the aisle to the window.  As a frequent flyer I automatically ensure that my seat-back is forward and my tray-table is "in its upright and locked position" at all the expected points in the flight profile.  But this time, when it came to landing, it got me thinking (again) about the policy-to-procedure "food chain".  Something seemed a bit over-kill-ish and I wasn’t sure at first why.

In particular I was ruminating on the requirement to put your tray-tables up and bring your seats backs forward during ground operations, take-off and landing.  Why?

So I started with the question: what could this requirement be fulfilling?

That’s easy: Safety!

But then: what is it about safety that this specific requirement fulfills?

That’s easy too: Avoiding injury in case of getting tossed about in the cabin plus the need for people to be able to get out of the plane in case of emergency.

OK.  But still: what’s going on that would lead to someone getting injured and/or being impeded from getting out of the plane in an emergency?

And that is when I realized what’s going on.

The requirement to put our seat-backs forward and our tray-tables up *is* over-kill in certain situations.  Well, the tray-tables part really is NEVER over-kill.  That’s *always* a good idea.  But, specifically, I was thinking about the seat-backs part as sometimes over-kill.

Like in the situation I found myself in.

FAA logoAirlines have to comply with the FAA’s regulations and create their own policies to do so.  In fairness, I have not read the FAA’s regulation on this, but since I am learning to fly, I’m generally familiar with the way in which flight regulations go.  Where it concerns passengers, the regulation is about safety, and it isn’t up to the FAA to tell airlines exactly how to make that happen.  Airlines don’t have to give you seats that recline, or tray tables to put your things onto.

So the airlines come up with policies to ensure they comply with the regulations.  And, then the airlines come up with processes to execute the policies and procedures to perform the processes.  Or, often, they just skip the process part and jump right into procedures.

You see, bringing up our seat-backs is a procedure intended to ensure a policy (and a regulation) is fulfilled.  But the policy (and the regulation) can be fulfilled in other ways.  Yet the airlines don’t provide flight crews with any other way and as a result, passengers are (sometimes) inconvenienced. 

Had the airlines created processes instead of procedures, then bringing up our seat-backs would be a function of whether or not anyone would actually be impeded by having our seat-backs reclined.  In the situation a few mornings ago, not only did I have an entire (half) row to myself, but the half row behind me was empty.  With no one next to me, no one behind me and an exit row several rows away, I could have left my seat all-the-way back and not bothered anyone’s attempt to get out of the plane in an emergency, I could have rested more comfortably during landing, and I wouldn’t have wasted a flight attendant’s time asking me to put my seat up (which didn’t happen since I did it anyway — but I’m just sayin’).

However, I’m not about to advocate for a change to airline policy on this point.  Really, there are many other factors to consider, and six seats with only one passenger in them isn’t common anymore so the likelihood of not needing to put-up our set-backs is rare.  The procedure is nearly 100% appropriate and for the less than 1% of instances where a better process would have helped, it’s entirely NOT worth it.  I’ll suffer.

In all honesty it wasn’t a big deal at all.  In fact the observation was merely mental gymnastics for me, but it did serve as good fodder to help explain the difference between policy, process, and procedure.