If you’re gonna do it… DO IT!

I was on the phone yesterday with a prospective client talking about bringing CMMI into an environment where the developers themselves have requested tighter processes. I was also told that they’re adopting Scrum (and possibly other Agile) methods.

In line with not wanting to pursue CMMI practices for the purposes of the appraisal and expecting to focus on the improvements, one point of potential resistance to change (which I find common at most companies — heck among most humans for that matter) came from the perceived expectation “from CMMI” for so-called ‘documented’ evidence.

First-off, I explained that the evidence required by the appraisal didn’t have to be a document, nor does it have to be created after-the-fact of the actual work captured by the evidence. This discussion took us into some particular areas of CMMI’s practices and the “findings” from the discussion are where the title of today’s post comes from.

Part of the resistance was from the potential burden on team leads and project managers to capture information from the daily Scrum meetings. I pressed for some examples of how their teams manage each Scrum, their Sprints or their backlogs and learned that all of that was rather ethereal as well.

In which case (if our conversation were on a Webcam, I could have emoted much more expressively), I was quick to point out that Scrum is a discipline. If they aren’t doing the things expected by the actual Scrum”™” approach, they’re not really doing Scrum… they’re just making themselves feel good about calling what they’re doing by a recognized Agile Method.

Not having a way of managing one’s work but calling what’s not being done by a name isn’t the same as actually managing the work. This is true regardless of whether there’s an attempt to implement CMMI. Certainly, implementing CMMI will cause this company some serious shifts in practice. But no more serious than actually following Scrum.