A starting point for a discussion on marrying Agile methods and CMMI.
15Mar

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

14Mar

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.

10Mar

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

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