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

What would agile auditing look like?

Expand Messages
  • David J Anderson
    No I haven t lost my mind!... In my blog post today, I speculate that the agile community is ready for agile quality assurance auditing for conformance to
    Message 1 of 216 , Aug 8, 2006
      No I haven't lost my mind!...

      In my blog post today, I speculate that the agile community is ready
      for agile quality assurance auditing for "conformance to agile
      process". See here.
      http://www.agilemanagement.net/Articles/Weblog/ThoughtsfromAgile2006.
      html

      and then this afternoon I was doing an edit pass on the MSF guidance
      looking for areas that need updating and I happened to read the
      definition of the Auditor role from MSF for CMMI Process Improvement
      (remember our CMMI method _is_ an agile method that just happens to
      conform to 17 of the 21 process areas in CMMI model level 3)

      Here is the text...

      About Auditor
      -------------
      An auditor is external to the project and offers an independent
      objective view of a project and its processes. The tendency for some
      organizations is to have this function serve as "process police."
      Following the team of peers mindset, this function should be more of
      a "process coach," with the initial assumption that everyone wants
      to do the right thing. An auditor effectively advocates and
      communicates for the product management constituency in the MSF Team
      Model by auditing the product and its processes and facilitating
      corrective action. The auditor is responsible for assessing the
      quality in the product as measured by quality control and the
      quality assurance measured as conformance against process
      definition. An auditor reports variance from specification, variance
      from plan, and variance from process definition. An auditor's
      reports can be used to assess the likely quality of the product and
      whether or not the organization exhibits control in its operations.
      A person assigned to this role should be added to the Contributor
      permissions group. This allows them to do all that they need to
      perform their function; such as create and modify the documents,
      work items, and work products.


      So my question to the group is, "What would agile auditing look
      like?" How can we improve on the role of auditor as it is currently
      defined in MSF (or in other CMMI implementations). Can we reinvent
      the process quality assurance function and make it part of a "high
      trust" organization, or is the idea of auditing always doomed to be
      part of a "low trust" and by definition NOT (so very) agile
      organization?

      David
    • Brad Appleton
      ... I certainly can believe that some projects have many parts of them that are deja vu . I have yet to see or hear of any project that has been 100% deja vu
      Message 216 of 216 , Aug 24, 2006
        Dean Schulze wrote:
        > I was responding to Brad's comment that every project is a research
        > project. Some projects are deja-vu.

        What I wrote was:
        > > Isnt every project a research project/learning experience
        > > to the extent that it has its own unique combinations
        > > of things.

        I certainly can believe that some projects have many parts of them that
        are "deja vu". I have yet to see or hear of any project that has been
        100% deja vu in every aspect and dimension of its project, process,
        environment, tools, technology, stakeholders, geography, culture,
        organization, and all of their inter-relationships.

        While I like FDD as a process, it is not so perfect as to never need any
        tailoring. In fact Ive yet to hear of an FDD project that didnt evolve
        (and tailor) its own process during the continued course of the product
        (ditto for an XP project for that matter).

        What concerns me most about the topmost statement above is that it
        suggests to me that even "some" projects are so deja vu that they
        present no tractable opportunity to learn and improve the process from
        one project to the next.

        When I stop learning, it probably means that Ive either stopped
        listening+looking with an open mind, or else it means Ive stopped breathing.
        --
        Brad Appleton <brad {AT} bradapp.net>
        Agile CM Environments (http://blog.bradapp.net/)
        & Software CM Patterns (www.scmpatterns.com)
        "And miles to go before I sleep" -- Robert Frost
      Your message has been successfully submitted and would be delivered to recipients shortly.