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.

Traction and Convergence

It's very 'interesting' the way the Universe works.

An article I'd had published 4.5 years ago was recently cited by a prospective client as one source of why they called today.

By itself that wouldn't be any big deal. However, coming on the heals of SEPG and other exposure (in part due to this blog) of the Agile CMMI concepts, makes one wonder about timing.

Clearly, the idea/need is catching on. One comment made by the caller, "...you used 'Agile' and 'CMMI' in the same sentence..." Something else she said was that she'd already interviewed some developers at the company. Their response was refreshing if not surprising: they were eager and enthusiastic about the idea of bringing more discipline into their space. Although they (claim to) use Scrum, the developers and team leads felt that CMMI would improve some areas they found needed more attention.

In any case, I hope things go forward with them so I can update what I find once I get there and maybe start working with them. It sounds like a really interesting place.

ON ANOTHER FRONT...

One of my clients did something really interesting. Background: They are using Scrum. They created User Stories and put them into a template for every Sprint that basically puts CMMI and other management-related tasks into every project. This ensures that certain time-consuming work isn't lost in the noise or consumed in unproductive time. They're making sure that the Backlog includes time to effectively follow their own processes (CMMI or otherwise) and produce the necessary materials (including setting up and use of their Scrum tool). I thought it was pretty neat.

It's quite a step forward in thinking -- really taking to heart the idea that the best, most unobtrusive yet disciplined processes are the ones that are built right into everyday work. And, one way to do that is to exploit existing tools. Together with portal technology, this client is really maximizing their bringing process to the developers without having the developers to figure out how to do their real work *and* "follow the process" at the same time.