Loading ...
Sorry, an error occurred while loading the content.

XP and CMMI?

Expand Messages
  • swoyerse
    Hey All, I m a journalist with Application Development Trends magazine (ADT, http://www.adtmag.com), and I m working on an article about agile programming in
    Message 1 of 4 , Jan 30, 2005
    • 0 Attachment
      Hey All,

      I'm a journalist with Application Development Trends magazine (ADT,
      http://www.adtmag.com), and I'm working on an article about agile
      programming in the enterprise. I've messaged many of you privately,
      and I thank all of you who've responded.

      With the encouragement of Ron and others, I've decided to post to the
      list directly. I've a question that I feel could perhaps encourage
      some interesting exchanges -- although I may be giving myself far too
      much credit. We'll see.

      I spoke today with a programmer who works for a very large technology
      services firm that's based in a blue northeastern state. He is unhappy
      with his job. (He's actually talked about transitioning to police and
      government work because he's so burned out on programming.)

      Anyway, we were talking about adherence to process and documentation
      in his organization, and when I asked him how he thought agile methods
      like XP might be accepted (even if they're only slowly incorporated),
      he seemed receptive to the idea. He loathes the amount of
      documentation he's required to create and peruse in his job, and (he
      says) when he finally gets around to coding (which can sometime take
      several months), he's lost all enthusiasm. At the same time, he
      expressed cautious skepticism, citing the example of a former employer
      that was also documentation-intensive, both because of its adherence
      to traditional waterfall planning, but also because of its ongoing
      CMMI efforts. The idea, I take it, was to try to instantiate process
      and repeatability by means of documentation (based on the premise that
      if you can document something, you can ensure that it's repeatable.
      Right.).

      This got us to wondering, are agile programming methods compatible
      with CMMI? I don't imagine that they'd be incompatible, or necessarily
      exclusive, but I did wonder if the CMMI index was itself an unfair
      scale for comparison. (That is, is CMMI too heavily premised on
      traditional, waterfall, approaches to project management?) So can the
      two be meaningfully compared?

      Also, do any you know of any examples of organizations that have
      reached the higher echelons of CMMI using agile methods? I'm not sure
      it's even an issue, but it's my impression that a lot of companies are
      sold on the prestige that's associated with upper echelon CMMI
      achievement.

      Finally, this programmer brought up the question of ISO 9001, which he
      says can place a premium on documentation as a means to ensure that
      quality management processes or controls are in place. (I'll plead
      complete ignorance on the ISO 9001 front.) I'm not sure if it was Jim
      Highsmith or Ron who suggested to me the idea of "barely sufficient"
      documentation, and I'm wondering if that approach will suffice for
      programming teams in ISO 9001 organizations.

      Thanks, as always, for your time. I apologize, in advance, if my
      questions are obtuse or otherwise mal-formed. I'm still learning here,
      after all.

      Best,

      Steve
    • Jeff Grigg
      ... We tend to think that a process needs to be more than defined and repeatable: It needs to be effective. ;- ... CMM, CMMI and ISO-900x certification has
      Message 2 of 4 , Jan 31, 2005
      • 0 Attachment
        --- "swoyerse" <lists@h...> wrote:
        > I'm a journalist with Application Development Trends
        > magazine (ADT, http://www.adtmag.com), and I'm working
        > on an article about agile programming in the enterprise.
        > [...]
        >
        > [A programmer] expressed cautious skepticism, citing the
        > example of a former employer that was also documentation-
        > intensive, both because of its adherence to traditional
        > waterfall planning, but also because of its ongoing
        > CMMI efforts. The idea, I take it, was to try to
        > instantiate process and repeatability by means of
        > documentation (based on the premise that if you can
        > document something, you can ensure that it's repeatable.
        > Right.).

        We tend to think that a process needs to be more than defined and
        repeatable: It needs to be effective. ;->

        > This got us to wondering, are agile programming methods
        > compatible with CMMI? I don't imagine that they'd be
        > incompatible, or necessarily exclusive, but I did wonder
        > if the CMMI index was itself an unfair scale for
        > comparison. (That is, is CMMI too heavily premised on
        > traditional, waterfall, approaches to project
        > management?) So can the two be meaningfully compared?

        CMM, CMMI and ISO-900x certification has been discussed a number of
        times on this list.

        My interpretation, from reading most of those messages is that XP,
        by itself, gets you pretty darn close to CMM level 3. I think you
        need to add some formal documentation /of the process/ (not
        technical documentation of your product) to pass CMM certification:
        You need to document that you're using XP, how that applies in your
        group, and how you've customized it with local practices. With a
        cooperative CMM auditor, you shouldn't need much else.

        However, CMM auditors seem to favor paper documentation, so a number
        of people have found that they need to maintain written
        documentation of project work, to demonstrate that they've followed
        the process. It turns out that most reasonable auditors will accept
        quite "light" documentation in this regard: You can save and file
        the User Story cards, when finished (instead of tearing them up).
        Hand-written notes for meetings, showing date, time, list of
        attendees, and a brief note on the topic or purpose of the meeting
        suffice. (Like, "Weekly planning meeting; entire team except Joe
        present." (Joe was on vacation that week.)) Many other CMM
        auditing requirements can be met with similarly light, quick and
        cheap approaches.

        > Also, do any you know of any examples of organizations
        > that have reached the higher echelons of CMMI using agile
        > methods? [...]

        CMM levels above 3 seem to require strong cross-company support and
        investment. It seems that XP teams and philosophies could support
        such efforts, but they're really outside of the scope of XP and most
        other software development methodologies: At the top levels,
        they're issues of how you run your business.

        The March 2001 issue of CIO magazine had a very interesting article
        about CMM. The article pretty much assumes that all the claimed
        benefits of CMM are true, but goes on to describe how many vendor's
        claims of CMM levels are misleading, and even fraudulent. "Buyer
        Beware!"

        http://www.cio.com/archive/030104/cmm.html


        > Finally, this programmer brought up the question of
        > ISO 9001, which he says can place a premium on
        > documentation as a means to ensure that quality
        > management processes or controls are in place. [...]

        I think you'll hit similar issues there. But I must too plead
        ignorance of ISO 900x. I've done CMM work, but not ISO 900x work.
        I think and assume that they are similar, based on my reading.


        > Thanks, as always, for your time. I apologize, in advance,
        > if my questions are obtuse or otherwise mal-formed. I'm
        > still learning here, after all.

        Good questions. Maybe someone else will byte...
        Maybe someone else will find some useful URLs, pointing to previous
        discussion and/or articles.
        - jeff
      • Gary Feldman
        ... When last I worked at an ISO 9000 shop, it reinforced the conventional wisdom - it s about making sure you re doing what you say you re doing, without
        Message 3 of 4 , Jan 31, 2005
        • 0 Attachment
          Jeff Grigg wrote:
          >>Finally, this programmer brought up the question of
          >>ISO 9001, which he says can place a premium on
          >>documentation as a means to ensure that quality
          >>management processes or controls are in place. [...]
          >
          >
          > I think you'll hit similar issues there. But I must too plead
          > ignorance of ISO 900x. I've done CMM work, but not ISO 900x work.
          > I think and assume that they are similar, based on my reading.

          When last I worked at an ISO 9000 shop, it reinforced the conventional wisdom - it's about making sure you're doing what you say you're doing, without regard to whether it's a good process or a bad process. Lousy software development processes can achieve ISO 9000, as long as they're well-documented lousy processes that are followed consistently. If you have a written process, can show that you're following it, keep your documents under control, track bugs, and some other basics, it's easy. The hard part is making sure that the college hire, who started two weeks earlier and was chosen at random by the auditor, can remember where the documents are kept and knows the difference between a printout and the official latest version. Other than that, there's no reason why an XP team can't get ISO 9000-3 certified as easily as any other team. Some things, like a brief, somewhat formal statement of the TDD process, fit right in. Documenting these things is annoying, but not di
          fficult.

          There are a lot of ISO 9000 auditing firms with good experience with manufacturing and limited experience with software. It's difficult for an auditing firm to really determine whether or not a software group is doing a good job.

          I don't mean this to belittle those groups that use ISO 9000 as a tool for improving their software quality. It's a useful framework for a place that's already committed to that type of formality, and it can be applied to process improvement. But it doesn't happen automatically, and certification says little about the quality of the software process.

          Gary
        • Robert Watkins
          ... This is actually one reason for the junior/senior split; junior members of staff are not expected (by the process definition) to know this sort of thing,
          Message 4 of 4 , Feb 1, 2005
          • 0 Attachment
            Gary Feldman wrote:
            > The hard part is making sure that the college hire, who started two
            > weeks earlier and was chosen at random by the auditor, can remember
            > where the documents are kept and knows the difference between a printout
            > and the official latest version.

            This is actually one reason for the junior/senior split; junior members of
            staff are not expected (by the process definition) to know this sort of
            thing, and are meant to be under the supervison of the senior staff (who do).

            --
            "Software is too expensive to build cheaply"
            Robert Watkins http://twasink.net/ robertdw@...
          Your message has been successfully submitted and would be delivered to recipients shortly.