Monday, March 06, 2006

SEPG Tribal Markings

This is a picture of my chest (oh, yeah) taken yesterday (Monday) at the SEPG conference.

Note the security badge is a wireless device and the brown surround is primarily a security device that communicates that I have access to the exhibition area as well as the conference. However, there is a subconscious tribal communication on the badge. It says - “I’m one of the exhibitor tribe” and one of the “SEPG conference super tribe” and “one of the Microsoft tribe”. My polo shirt re-iterates that. I’m a Microsoftie! But note the pins stuck to my shirt below the Microsoft logo. These are tribal markings - stripes of individual value in the SEPG tribe. I’m a “presenter” and my employer is an “SEI Partner.” I’m not sure why they gave me the “Reviewer” pin - I don’t think I deserved it. So today, Tuesday, I didn’t wear it. All of this communicates that I’ve arrived in the SEPG tribe. [For any of you reading this and also attending the event, I look forward to seeing you in my session at 3.30pm on Thursday.] Technorati tag: Agile, David+Anderson, CMMI, SEPG

Thursday, February 23, 2006

Who’s calling FDD an Oxymoron?

Jim Brosseau suggests that agile methods built around a state model for work items are an oxymoron. Jim clearly isn’t familiar with FDD which has six states for its Features, namely, walkthrough, designed, design reviewed, coded, peer reviewed and unit tested, and promoted to build. However, even the simplest of processes have states for work items. Imagine an XP process with index cards for stories and the stories pinned to a notice board in three sections, namely, not started, in-progress, and complete. I simply can’t agree with Jim that state models and agile processes don’t mix.

Jim also suggests that Microsoft selected Agile and CMMI as the targets for MSF v4.0 from del.icio.us tags for the buzz they will create. Sorry, Jim, wrong again. Actually, we did market research with our real customers and they told us that what they wanted was either an Agile process or a CMMI process. We are actually responding to market demand.

Jim continues that, “<!—StartFragment—>building a generic CMMI process model for enforcing the development of software is like talking by building a sentence model around Webster’s Dictionary.” I’m guessing he hasn’t actually seen what we came up with. Because not only is our CMMI method perfectly viable as a workable process for software engineering, it is agile too, and innovative in how it demonstrates its ability to meet the appraisal requirements for a SCAMPI appraisal.

Jim, we’d be happy to have you come visit us at Building 25 on the Redmond campus, if you’d like to learn the facts.

[Disclosure: My employer put me up to it but the words are all mine.]Technorati tag: Agile, David+Anderson, FDD, MSF, CMMI

Wednesday, July 27, 2005

Stretching Agile to Fit CMMI Level 3

Here is the paper and the presentation slides that I presented today at the Agile 2005 conference.

Download Stretching Agile to Fit CMMI Level 3 - the story of creating MSF for CMMI Process Improvement at Microsoft [Paper PDF 342K] [Presentation PDF 829K]

I have to say that I was very pleased to see the room full - there is so much great stuff at the conference and to get 30 or 40 people for a CMMI experience report was a really good turnout. The audience also really seemed to like the presentation and greatly appreciated the work we’ve been doing to articulate the intent of the CMMI and make agile software development practices acceptable to the appraisal community.

[Update: Dec 14th 2005. I got some review comments from Jon Gross at the SEI. I’ve incorporated most of Jon’s comments and issued an updated version of the paper 1.6]

Thursday, July 07, 2005

CMMI and the Declaration of Interdependence

Back in February, I was involved in the creation of rallying cry for the adoption of agile techniques in project management. We called this the Declaration of Interdependence - six statement which we felt differentiated the agile approach from traditional teaching in project management. You can read my personal interpretation of each statement here: [1]; [2]; [3]; [4]; [5]; [6]. Shortly after publication I was challenged (via my Yahoo! group) to state how the DOI differed from existing project management frameworks such as the CMMI IPPD from the Software Engineering Institute. My initial reaction was to state that as the CMMI was a framework which didn’t prescribe specific practices it was likely to be compatible and despite frameworks like the CMMI, it was still possible that many project managers were practicing techniques which were damaging. I promised to do an analysis and post it here when it was done.

After 9 months of being deeply immersed in the CMMI whilst producing MSF for CMMI Process Improvement, including two visits to the SEI at Carnegie Mellon University in Pittsburgh, PA, I’m finally ready to make good on the promise - a gap analysis of the DOI against the CMMI.

[DOI] We increase return on investment by making continuous flow of value our focus.
[CMMI] The CMMI is pretty agnostic on this. It’s a “so what?”. It doesn’t break the CMMI nor does the CMMI ask us to do anything differently. Although the CMMI is written in a project-centric fashion, it does not rule out small increments of delivery.
#1 is compatible!

[DOI] We deliver reliable results by engaging customers in frequent interactions and shared ownership.
[CMMI] The CMMI actively encourages stakeholder involvement and has explicit activities for monitoring it.
#2 is compatible!

[DOI] We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
[CMMI] The CMMI is founded on the principles of W. Edwards Deming, his Theory of Profound Knowledge, the theory of variation and the concepts of special and common cause variation. Although some explicit text talks about “plan the plan, plan the work, work the plan” and has very “conformance to plan” language in some of the practice guidance, there is nothing about uncertainty, variation, adaptive planning, iterations and anticipation that is incompatible with CMMI. In fact the new MSF for CMMI Process Improvement does these things explicitly.
#3 is compatible!

[DOI] We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
[CMMI} The CMMI is very big on the idea of creating an organizational environment for success (where success is defined as achieving continuous improvement - in a quality assurance sense). There are explicit process areas around training and organizational environment. There is nothing in the CMMI which is incompatible with the DOI’s embrace of innovation and creativity and its underlying principle that people are assets rather than fungible cost centers.
#4 is compatible!

[DOI] We boost performance through group accountability for results and shared responsibility for team effectiveness.
[CMMI] Though many formal organizations which follow the CMMI use RACI designations and have individual accountability, the CMMI is really agnostic to this. What it asks for is that the agreement is written down in a Team Charter. Again, with MSF for CMMI Process Improvement I have designed it to exhibit group accountability and shared responsibility style with the team of peers concept carried over from earlier versions of MSF. This is perfectly compatible with CMMI.
#5 is compatible!

[DOI] We improve effectiveness and reliability through situationally specific strategies, processes and practices.
[CMMI] The CMMI explicitly expects situationally specific practices and processes and encourages it with explicit activities aimed at tailoring processes and practices for specific projects.
#6 is compatible!

Asking the question the other way, “Is there anything in the CMMI which is incompatible with the DOI?” is also an interesting question. There are 25 process areas in the CMMI. However, my take on it is “No! There is nothing at the process area and goal level which is incompatible with the DOI.” The problems arise at the interpretation of the specific practices. The DOI was born out of observation that project management practices as taught in so many places are leading to undesirable behavior and unfavorable results. The DOI seeks to reset the mind set (or paradigm) of how people think about projects so that they adopt the correct behavior that leads to good results.

It’s perfectly possible to be an agile project manager and be running a CMMI compliant process.

Wednesday, March 16, 2005

MSF for CMMI

So the cat is out of the bag, with respect to the work I’m doing for Microsoft. Last week at the SEI’s SEPG convention, we announced MSF for CMMI(R) Process Improvement - an MSF process instance which is enacted in Visual Studio Team System. We got a very positive reaction to the concept from convention attendees. We got some positive reaction from the press too - see this Yahoo article.

It’s been a learning experience for me. When you set an agile guy loose on a formal traditional software engineering problem such as CMMI conformance something unusual is bound to happen. For me, it was the discovery that the CMM was inspired by the work of Edwards Deming and the realization that levels 2 through 4 are all about special cause variation with level 5 being about continuous improvement (or reduction of common cause variation). Coupled to the transparent traceability of work items and work products, this opened the door to the agile management solution for CMMI. MSF for CMMI(R) Process Improvement will be a lightweight process. We’ve taken a stretch-to-fit approach by stretching our MSF for Agile Software Development process and adding just enough to meet a CMMI Level 3 appraisal. We’re targeting Level 3 this year and will go for a Level 5 solution later.

We’re going to be using a lot of agile management techniques including velocity, cumulative flow and uncertainty buffering with unplanned work charts. Anyone familiar with the material at this site will know that I’ve done a lot of the groundwork on a Deming style solution for software engineering. To further break with tradition, we won’t be offering time on task estimating and tracking, earned value and critical path or much of any other traditional PM guidance as standard elements. We do recognize that there are many people in the market who need these things - particularly through government mandate. So we’ll be providing guidance on how to swap them in and users who want EV, CPM and time tracking can still do it with the MS Project interface to Team System. However, out of the box, it’ll be a lightweight, agile approach to CMMI.

Because this is quite radically different and threatens to actually deliver a truly democratized CMMI process for the rest of us, we’ve had to pull in some heavyweight advisors and collect data points from other respected members of the community, to ensure that we’re not crazy and that we can meet the spirit and the letter of the CMMI law (err, goals). This is one of the cool aspects of working for Microsoft which wouldn’t be possible for me as an independent consultant. I get to work with people like Mike Konrad who looks after the CMMI model for the SEI and Jack Ferguson who guides the appraisal side. I’ve taken other data points from Bill Curtis who owned the SW_CMM for a long time and now through the recent acquisition of Teraquest, is Chief Process Officer at Borland, and Watts Humphrey who started the whole thing off 17 years ago with a dream of delivering a Deming solution for software engineering. Overall I’ve had a very positive reaction from these experts. It’s validation that it may be possible to deliver an agile, lightweight, low overhead, low bureaucracy CMMI solution. [Naturally, there are lots of others providing input and guidance on this project and they all know who they are.]

So now I need to deliver on the promise. Time will tell whether I get it right. I’ll be saying more about this publicly around TechEd in July.