Moving week...

Not much work getting done this week on account of our moving cities. Sounds more dramatic than it really is... at least in terms of the actual distance of the move. For some folks, not familiar with the US's East Coast "megalopolis" that runs from Boston to Richmod, VA (some say it doesn't go farther south than Washington, DC), it may sound odd to say we're "moving cities" when we're really only about 37 miles (59km) from our previous home. Practically speaking, we could have moved the same distance in almost any other direction of the compass and we would have still been in the Washington, DC suburbs. In any case, we've moved from the suburbs of DC to the suburbs of Baltimore (Maryland) for many reasons, though dominated by the proximity of our new home to family.

So here we are, amidst a floatilla of boxes, trying to find our stuff. Thanks to the less-than-spritely response time of the 'big iron' dominant phone power of the region, my voice/data lines don't get installed until the 30th... Right now I'm 'borrowing' bandwidth from a neighbor's entirely unsecured wireless access point. ;^>

I might write about the ordeal of moving, or the games being played by the he-was-being-such-a-jerk-it-was-all-I-could-do-to-not-hit-him buyer's real estate agent on the day of moving/closing/settling.... maybe I'll write something about a funny exchange between my mom and me about our differences in how we value planning vs. priorities vs. rework... but what I hope to do is to find an Agile CMMI thread to this week's events and write about them.

Someday.

I would probably need to find the humor in all the week's stress before that happens.

Stay tuned.

MA in T&M

Well, while profit (or "programmatics") is (are) the most "key" of business performance indicators when the contract is T&M, it turns out that there are valuable process metrics even in that scenario.

Admittedly, there's a small (and arguably fictitious) loop-hole in the MA (Measurement and Analysis) process area in CMMI. In brief, the  MA process area  expects  companies to  identify  business goals and to find metrics from their practices that provide valuable business analysis / intelligence to further those goals.  Whether those metrics provide insight into process improvement or only into programmatics is the potential loop hole.   We can discuss that another time.

I'd considered the 'incentive' aspect as Wayne points out, but that's a matter for those who fashion the contract.  Collecting metrics on or even influencing the contracts decision might be beyond the powers of most process improvement practitioners.  -- Though I would say that in an ideal world, executives making contract decisions would be doing so with an eye towards their process improvement efforts and more than just profit, but let's be real.  Those types of executives are far fewer than the kind the rest of us work with.

Back to our scenario... A common metric is estimates to actuals, but when the estimate is feature/functions, not time or budget, this becomes somewhat problematic, right?  And, when the developer is using Scrum to manage development their ability to spend their allocated budget and deliver a product the client is happy with is pretty good. 

What can we still learn from estimates to actuals on functions even when it's a seemingly feature-poor process metric?  How about giving management data that tells them they can go and sell more business without increasing staff?  E.g., "we so (over)|(under)-estimated what we could do that we could have (broken this up into several $20k jobs) | (sold more time during this period of performance)", etc.

Try that on.

Lesson learned...

When publishing from email... make sure to send it as plain text and don't
let your email client format your entries... the div tags mess things up
ROYALLY!

[This is another emailed blog post... As (hopefully) proof of my theorem.]

Agile, Metrics, and T&M

An interesting conversation took place with a client today.

I suspect many development shops using agile methods may run into the same issues. Namely, agile development methods arguably run counter-current to fixed-price contracts and therefore agile shops are often found in relationships with their clients where they are compensated for Time and Materials (T&M). This works especially well with development approaches that re-scope the feature/functions to meet the schedule and/or the available budget rather than constraining the the developer to deliver all features/functions regardless of the exposure to themselves (a la, "Fixed Price").

So consider the following scenario: a developer managing its development using Scrum has a client with a fixed budget to spend on the developers to deliver a set of features -- but doesn't necessarily expect all the features to be delivered as long as a good value has been delivered. The developers work to deliver as much as they can and burn off the hours -- and their goal is to not leave any hours un-burnt.

In this scenario, the only business metric the developers' CEO cares about is whether they've burnt all the hours. Assuming they delivered a quality product and the client is happy with the value, the metric here is pretty simple: profit. The client will pay the maximum budget and regardless of how efficiently the developers have worked, the company will make the same amount of money.

In comes the CMMI process area of Measurement and Analysis (MA)... which expects the company to be collecting metrics based on business objectives -- presumably to help improve the process. However, in a T&M situation, what metrics are really any more important than whether or not the company spent all the hours? What's the incentive to deliver more of the functions and burn less when they don't get paid for what they don't spend?

I hope to generate some discussion on this point and I'll post what we ended up doing in the next day or so -- I'm here to learn as much as anyone else. :-)

[By the way, this was also my first test of emailing blog entries... I hope it didn't suck.]

Documentation vs. Evidence

A conversation I've now had a number of times, including on the Agile v. CMMI panel at SEPG deserves special mention.

The appraisal process for CMMI which looks to see that an organization has a process improvement program in place (called "SCAMPI") doesn't explicitly require "documents" as artifacts. Neither does CMMI itself.

What is required is "evidence".

Evidence is not always documentation.

One enabler of CMMI in Agile/agile environments is this distinction. I expect to write more about the SCAMPI process soon enough.

An Email Thread

NOTE: The following message was graciously sent to me yesterday. I've received permission to post it to the blog and I'll also post my reply.

Dear Mr. Glazer,

I'm an Agile supporter since before the word Agile had been chosen to identify this group of approaches. I served the Agile Alliance board of directors for two year and was previously (heavily)involved with the Rational Unifed Process and CMM. This is just to say that I'm supposed to have some real world, day to day experience, not to impress you in any way :-)

I believe, like you, that at some level Agile and CMMI can cooperate
without problems but I think tradeoffs are needed mainly in principles and perspectives.

What I can see working is, as you write, wrapping agile practices with CMMI:

- agile practices for software development
- CMMI for software management

As you can see I'm using 'agile practices' instead of 'Agile' because I think this is the biggest tradeoff you need to do in order to integrate both. Otherwise I think they should really be kept separated.

I'll try to explain myself: every organisation can improve its process adopting one or more agile practices without becoming Agile and I think this is fine as far as it serves its purpose and I see it fitting lots of realities. You know, at the end an approach needs to fit the organisation culture otherwise it will have hard times.

That is because I don't agree in saying that Agile is just a bunch of (engineering) practices. As I'm sure you already know an Agile approach *requires* a mentality shift for the organisation as a whole.

XP is Agile but Agile is not XP and, for example, Scrum is 90% about
management, and it's fully compatible with XP while in its fundamental principles it is not with CMMI.

I'm interested to know more about your phrase: "where XP ventures into management methods, they are not incompatible with CMMI" for two reasons:

1) because while I have practical experience with waterfall, RUP, CMM and Agile (above all) I've just read about CMMI and I don't like to speak with theoretical knowledge only

2) because I like to know more :-)

Even if I tried to keep this email short I failed even if I feel I would need pages and pages just to put some order into my thougths.

Thanks in advance for your time, regards

Marco Abis
http://www.agilemovement.it :: Italian Agile Movement
http://www.agilityspi.com - Agility Software Process Improvement
http://www.thoughtworks.com - The Art of heavy lifting

My Reply:

Marco,

Thank you so much for writing!

I agree that we should be careful about how we use "Agile" and "agile".
I will try to be more careful and consistent in the terminology.

I also agree that agile is more than engineering, especially when we want to look at agile as a change in development practices at a very fundamental level, beginning with addressing the very paradigms of engineering practices.

On the matter of Scrum, however, I would have to disagree with your assertion that the approach is incompatible with CMMI. In fact, I love the impact Scrum has on an organization's CMMI practices. Perhaps (you tell me) your position comes from experience with the strong implication in the SW-CMM (not CMMI) and in the assessment / evaluation method for SW-CMM on documentation which would be hard to satisfy w/Scrum. In that regard, CMMI is a marked improvement over SW-CMM.

The reason I see "management" aspects of XP to be compatible with those of CMMI is because the two "bodies" are actually addressing different (non-overlapping) aspects of management. More importantly, both have, at their core, strong influences of what "good management" is.

At today's SEI SEPG Conference, David Anderson nicely presented a view of Agile's Principles as they reflect Deming's TQM principles. The coverage was complete. Neither set exluded the other.

Now, a question for you before we continue this thread: until I integrate a bulletin board onto the blog page, would you mind if I blogged your email & my reply and we continued our discussion there?

Cheers!!
-->> Hillel

Back from SEPG -- Very pleased!

All-in-all the event was a success for me and Entinex. Today's panel discussion on Agile & CMMI went well, I thought... If a measure of success can be the fact that most of the audience stuck it out for the entire double-session w/out taking even a bio-break and then stayed on after the allotted time and into the afternoon refreshments break... I guess you could say it was pretty high-value.

The panel was excellent. Each person had a different perspective on the matter which did add depth -- even though we all pretty much agreed that CMMI and agile methods are not incompatible. I'm sure a more lively panel would have been one that also included an agilist and a "big" process person who didn't believe the two can play nicely, but I think it was important that a group of people with different perspectives came together to make an essentially unified front in moving this topic off the "no way" list and into the "let's make it happen" list.

From the panel I shamelessly plugged this blog (with the moderator's consent) as a place where those who agree (or are at least at a point where they can carry on a serious, productive discussion and investigation) can collaborate and discuss the topic. I've created a discussion group for it and will see about making a companion bulletin board or RSS/Atom feed to it here. (In my copious spare bandwidth.)

David Anderson's impressive presentation near the very end of the day had some really killer information. What he's working on over there in Redmond should take this business by storm. I'm looking forward to heading out there this summer to get an up-close and personal tour of their work.

I'm really quite feeling accomplished at all the great people I met there and anyone reading this whose name doesn't explicitly appear in these posts, please don't be offended. The discussions and serious issue-hashing were informative and productive. There are many of you with whom I hope to be in regular contact to move this matter forward and ultimately make it a non-issue. Technical Reports are already in the making, but they will need people to carry the message and this space is what I hope we can use to make that happen.

2nd Full Day at SEPG

Let's just start by saying that David Anderson is *way* too generous. His post about me is simply humbling.

So that's how day 2 started. And it was just as good (or nearly) for the rest of the day.

Right after lunch (mixed blessing) I delivered my session on "Time to Market vs. Process Discipline" to a suprisingly large audience. I guess the topic title alone struck a chord. And, if the number of people coming up to me for updated slides and other discussion are any indication, the material was well-received. I got many "thanks for saying what you said" comments as well as many other nice things from strangers as well as people I know. I value everyone's thoughtful opinions and feedback. Here and there discussions ensued over the course of the afternoon long after the session. I hope the general session feedback forms provide useful improvement points.

I attended a very fun session on "Behavioral Clues" of process maturity delivered by one of my CMMI mentors, Judah Mogilensky of Process Enhancement Partners. It wasn't only about "Bottom-Dwelling Mud-Sucking Level 1" companies(TM)*, but also about behaviors of higher-maturity. Quite informative.

*a non-official term of endearment used around the CMMI community for companies just getting started on improving their processes and who are so lost and clueless you can't help but think they're cute... like a puppy or kitten.

The session after that was on Agile implementation in a very data-driven company. I was very happy to see their material because I hope it laid to myth that Agile development doesn't generate manageable data.

The final session was a break-out session after-hours to discuss in an open forum the being done on creating a CMMI set of practices around organizations that deliver pure services, no products. It was rather lively and I hope to get more involved.

In all, a good day for Agile CMMI. I am continually stunned at how many people agree with my philosophy on Agile development + CMMI and yet how few are out there actually doing it.

Tomorrow is a panel discussion. Looking forward to it.

First full day @ SEPG 2006

After breakfast I decided to walk the mile or so to the convention center. That was a mistake from several angles. I ended up arriving about when I would have had I waited for the shuttle van and for my industriousness I was rewarded with a sinus headache that wouldn't go away all day. (My stash of "Day-Quil" was back at the hotel.) My Transition Partner, Galina (to whom I owe my SEI/CMM/CMMI independent consultant start, by the way) hooked me up with some anti-histamines and a Ricola losenge... I think the losenge did more than the drugs.

The sessions I attended were quite good. So were the opportunities to network. I met-up with the guy coordinating a panel discussion which I'm part of on Thursday and learned that a 4th panel member got his travel plans messed up. A few minutes later I run into David Anderson again and *presto* we have ourselves a 4th panelist. (Thanks David!) We sat next to each other at the next session and were able to squeeze in a few words here and there.

During a break I met with a Senior Editor from a publishing company who wants me to send in an outline for a book I'm writing: How to Get from Estimates to Actuals In the Black.(link is to page of presentations)
Come to think of it, I should make that a blog too. Stay tuned I suppose. (David A. what have you done?!) ;-)

Another positive note is that I had it confirmed for me that the only thing standing between me and getting the authorization letter from the SEI to be a fully Authorized Lead Appraiser, is for the guy in whose inbox the paperwork is sitting. The head honcho, who's always on the road, so stuff like that can rest there for a while.

At the evening reception I spent time talking martial arts with David Greer (a Transition Partner who generously arranged for me to be observed teaching Introduction to CMMI which got me that 'authorized instructor' credential really fast for a lot less money than had I tried to arrange it on my own). One of his aquaintences, whose name must remain confidential for what I'm about to say, tells me that she was talking to a cellular supplier in need of process help. She hung up when the VP of this company couldn't explain what she meant by "someone who can help us implement Agile methods who's also strong in CMMI". The part that earned her the dial-tone response was when this VP couldn't explain what she wanted from Agile or how they wanted to implement it.

In the end, David (Greer)'s friend took my card and told me she'd call the VP with my 411.

Head ache or not... not a bad day. This Agile CMMI stuff is really gaining traction.

Before I sign off I should make note of a couple of things about the conference.

Let's start with these bulky but grows-on-you name badges they've issued every attendee. They're about 4" x 4" X 1" and are attached to a lanyard with both ends on spring-loaded spools. Though awkward as a thing to wear around your neck they're loaded with features and I admit I had not expected to use any of them. Turns out that one feature is terribly convenient... like... grabbing names of anyone you spend a little face-time with and for people you really want to keep track of you can "beam" each other your contact info. You can even use the thing to submit session reviews. The thing is constantly aware and will flash information about you to people as you walk by, but it will also flash a message to an onlooker about themselves... Like I caught it telling an exhibitor to hold his tag up higher. Nifty.

Next I want to mention that I really feel the SEI is going all-out to welcome SEI members. They've set up a lounge whose couch my aching head sorely needed and if promotional do-dads are any measure, they're really giving us some useful stuff.... not kitsch.... beyond the snappy briefcase everyone got.

In any case, I'm having a good time and the experiene has been far more positive than I expected. Next year's conference is in Austin. Hee ha cowboy!

I've been convinced to start a blog.

So I'm at the Software Enginering Institute's main anual conference (SEPG 2006) in Nashville and I run into none other than Microsoft's David J. Anderson who basically brow-beats me into writing a blog.

So... here it goes.

As a first entry I should probably make some mention of who I am and the sort of things I'm up to, but I can do that by pointing you towards my company Web site 'about us' page here.

Caught up yet?

Don't worry.

Let's just say I'm finding myself among the few who believe CMMI and Agile methods are not only possible but are, in fact, not at odds whatsoever. What makes my position on the matter somewhat unique (it turns out) is that I'm an authorized CMMI instructor and SCAMPI Lead Appraiser.

Let's just close-out this entry with a few thoughts... perhaps this will be what drives the remaining posts... pehaps not, but it certainly frames much of the discussion I have on Agile CMMI:

• CMMI® is about software process management, not technical development and doesn’t care what development methodology is used.
  
• The key to marrying Agile and CMMI is in distinguishing between
  
  • software development methodologies and
  • software management methodologies.

Here's something I find absurd:

• Too many "Disciplinarians" believe "Agilists" think :
  
  • "We’re out to produce quality software in the absence of any process."
• Too many Agilists believe Disciplinarians think:
  
  • "Process is more important that productivity or profit."
• BOTH are absurd and neither perception is true.

So with that in mind, here's where I stand:

• It’s not the absence of process that makes a development method agile… It’s the absence of unnecessary or obstructive processes that makes a method agile.
  
• Take the time to:
  
  • Understand the risks processes are trying to avoid.
  • Design the processes in alignment with productivity.

Hope to "see"you soon.