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

Appearance and thoughts from ASQ World Conference

Earlier this week I attended ASQ’s world conference. I wasn’t able to enjoy much of what was offered on account of several other things going on in my work and home life, but I was able to hear the opening speaker’s remarks.

David Kohler of the company bearing his name spoke on how quality “shows up” in their company and how they manifest quality as both a concept and a strategic enabler.

(“quality” has many definitions, but in this entry, you’ll see how it’s being used without further elaboration)

What struck me most was how thoroughly this man (and supposedly their company) understood what it takes from leadership to infuse ‘quality’ into an organization. The level of involvement and commitment by leadership to become and sustain a company where quality isn’t just a passing marketing fad was clear:

To be and sustain that kind of company takes leadership who fundamentally understands that:

  • Quality isn’t a single measure, there are many perspectives on quality, including product, process, market, perceptions, and inwardly-oriented measure as well;
  • Quality doesn’t only happen on the manufacturing floor, it happens in marketing, design, product and brand management, executive offices, HR;
  • Quality takes time to achieve, just like anything that we want to stand the test of time, quality takes time to build, time to get it right, and time to work out the kinks… and time to allow for and expect everything to be continuously revisited and changed to reflect current forces; and,
  • Quality take commitment, commitment to see it through and to allow it to happen even when it costs time, money, resources or delivers bad news.
  • Companies that don’t understand or have never experienced the kind of commitment it takes to build a quality-focused organization may only ever come to understand what it takes when they truly understand exactly how their companies work. CEOs who parachute into an organization rarely have this kind of knowledge, and even more rarely take the time to get the operations under their own skin. — Merely directing that quality be a priority without actually knowing what it takes is asking for failure. Successful CEOs will know exactly how shifts at the working level will affect quality and how that will, in turn, affect profit.

    A brief conversation with one of Kohler’s Quality Engineers on the exhibit floor confirmed for me that quality wasn’t a marketing catch-phrase.

    Also at ASQ’s conference, I delivered a 30 minute talk on CMMI and Agile from the perspective of shifting how people implement quality assurance as a means of broadening the concept of “disciplined processes”. It was very well received. One thoughtful question asked afterwards was about Agile methods in government contracting spaces for very large government contractors… that one, unfortunately is still an issue I’ve yet to fully flesh out… the complications of the way the government writes contracts as well as a host of other attributes makes Agile in the Government Space a tricky matter.


    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.


    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.

    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