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

Re: [XP] cmm and agile?

Expand Messages
  • PaulOldfield1@compuserve.com
    (responding to Will) ... (donning flame resistant suit) It depends why your company is pursuing CMMI and their attitude as they go about it. If they are
    Message 1 of 21 , Mar 23, 2004
    • 0 Attachment
      (responding to Will)

      > I have a dilemma here...our company is pursuing CMMI compliance,
      > yet the projects and teams are small enough where an agile
      > approach makes the most sense...and I would like to apply an
      > agile approach to our company's methodology playbook.

      (donning flame resistant suit)

      It depends why your company is pursuing CMMI and their
      attitude as they go about it. If they are genuinely interested
      in software process improvement, and going about it effectively,
      they might not arrive at XP, but will arrive at something that is
      suitable for the work you do.

      The problems arise when CMM/I are pursued with a "tick the
      box" mentality rather than a genuine desire to improve
      process, or where the basics of software process improvement
      are not understood. It's worth asking the person running
      the SPI effort "If XP were the most appropriate process, would
      your efforts result in XP?"

      It would also be useful to have somebody with a deep
      understanding of agile approaches on the SPI board (or
      whatever you call it in CMMI) so that any non-agile
      assumptions can be questioned at source.

      Paul Oldfield
      www.aptprocess.com
    • Brad Appleton
      ... Just wanted to say how much this resonates with my own experience. I work in a large organization that is pursuing CMM/CMMI maturity levels. Some parts of
      Message 2 of 21 , Mar 23, 2004
      • 0 Attachment
        On Tue, Mar 23, 2004 at 03:19:50AM -0500, PaulOldfield1@... wrote:
        > It depends why your company is pursuing CMMI and their
        > attitude as they go about it. If they are genuinely interested
        > in software process improvement, and going about it effectively,
        > they might not arrive at XP, but will arrive at something that is
        > suitable for the work you do.
        >
        > The problems arise when CMM/I are pursued with a "tick the
        > box" mentality rather than a genuine desire to improve
        > process, or where the basics of software process improvement
        > are not understood. It's worth asking the person running
        > the SPI effort "If XP were the most appropriate process, would
        > your efforts result in XP?"

        Just wanted to say how much this resonates with my own
        experience. I work in a large organization that is pursuing
        CMM/CMMI maturity levels. Some parts of the organization
        are allegedly at the highest levels and parts of those
        organizations are practicing agile methods. They certainly had
        to make adaptations to fit and align them into their culture,
        but they are managing to be agile and (more importantly)
        successful and productive.

        CMM and CMMI (and their advocates) say that the CMM/CMMI
        frameworks state WHAT should be done, but do not profess to
        state HOW it should be done. While there is certainly room
        to debate if some of those things really are needed, there
        is also plenty of room to make a strong case for an agile
        method as a specification of HOW in a way that successfully
        implements the CMM/CMMU "interface".

        --
        Brad Appleton <brad@...> www.bradapp.net
        Software CM Patterns (www.scmpatterns.com)
        Effective Teamwork, Practical Integration
        "And miles to go before I sleep." -- Robert Frost
      • chapmanstick2002
        ... Good points. Luckily I think we are in a position where PI is desired for the sake of PI, and I have experience in a shop that successfully used XP...so I
        Message 3 of 21 , Mar 28, 2004
        • 0 Attachment
          --- In extremeprogramming@yahoogroups.com, PaulOldfield1@c... wrote:
          > (responding to Will)
          >
          > > I have a dilemma here...our company is pursuing CMMI compliance,
          > > yet the projects and teams are small enough where an agile
          > > approach makes the most sense...and I would like to apply an
          > > agile approach to our company's methodology playbook.
          >
          > (donning flame resistant suit)
          >
          > It depends why your company is pursuing CMMI and their
          > attitude as they go about it. If they are genuinely interested
          > in software process improvement, and going about it effectively,
          > they might not arrive at XP, but will arrive at something that is
          > suitable for the work you do.
          >
          > The problems arise when CMM/I are pursued with a "tick the
          > box" mentality rather than a genuine desire to improve
          > process, or where the basics of software process improvement
          > are not understood. It's worth asking the person running
          > the SPI effort "If XP were the most appropriate process, would
          > your efforts result in XP?"
          >
          > It would also be useful to have somebody with a deep
          > understanding of agile approaches on the SPI board (or
          > whatever you call it in CMMI) so that any non-agile
          > assumptions can be questioned at source.
          >
          > Paul Oldfield
          > www.aptprocess.com

          Good points.

          Luckily I think we are in a position where PI is desired for the
          sake of PI, and I have experience in a shop that successfully used
          XP...so I can use that as we head down the path.

          I don't fully understand the question: "If XP were the most
          appropriate process, would your efforts result in XP?" I can sort
          of see what you're getting at but not fully, in the context of CMM.

          will
        • Jeff Grigg
          ... My concern would be that the person running the SPI effort would smile and say, Why yes, of course it would. ...and given that your concerns had been
          Message 4 of 21 , Mar 28, 2004
          • 0 Attachment
            --- PaulOldfield1@c... wrote:
            > It depends why your company is pursuing CMMI and their
            > attitude as they go about it. [...]
            >
            > The problems arise when CMM/I are pursued with a "tick the
            > box" mentality rather than a genuine desire to improve
            > process, [...]

            > It's worth asking the person running the SPI effort
            > "If XP were the most appropriate process, would your
            > efforts result in XP?"

            My concern would be that the person running the SPI effort would
            smile and say, "Why yes, of course it would." ...and given that your
            concerns had been successfully dismissed, go on to say, "Now, what
            are you doing to guarantee that all the requirements are correctly
            gathered and documented up-front -- as that's known to be 'industry
            best practice.'"

            Such a direct pass/fail question strikes me as an invitation to lie.
            _ _ _

            Further, suppose that a Software Process Improvement effort started
            with waterfall and honestly and consistently worked to improve it
            over time. Would they end up at XP (or some similar agile
            process)? How could one get sufficient automated testing support
            for refactoring to be safe through small incremental improvements?
            And even if they would, in theory, eventually get to XP, would you
            still be alive by then? ;->
          • PaulOldfield1@compuserve.com
            (responding to Will) ... One of the problems I encounter in attitudes toward process improvement is the timeworn heuristic, the old saw that everybody just
            Message 5 of 21 , Mar 28, 2004
            • 0 Attachment
              (responding to Will)

              >> (Paul)
              >> The problems arise when CMM/I are pursued with a "tick the
              >> box" mentality rather than a genuine desire to improve
              >> process, or where the basics of software process improvement
              >> are not understood. It's worth asking the person running
              >> the SPI effort "If XP were the most appropriate process, would
              >> your efforts result in XP?"
              >
              > (Will)
              > I don't fully understand the question: "If XP were the most
              > appropriate process, would your efforts result in XP?" I can
              > sort of see what you're getting at but not fully, in the context of
              > CMM.

              One of the problems I encounter in attitudes toward process
              improvement is the timeworn heuristic, the old saw that
              everybody just accepts to be true, because it was once true,
              in any context, about a decade ago. Things like the idea that
              "Traceability is a Good Thing". Things like the idea that "We
              must write down our process".

              In asking the question "If XP were the most appropriate
              process, would your efforts result in XP?" you might get
              answers along the lines that "XP could never be the most
              appropriate process because...". You are lucky, and start with
              the knowledge that many people *do* find XP to be the most
              appropriate process, so there must be some underlying flaw
              in the reasons given. In a CMMI environment, once you have
              detected the point at which the underlying logic appears to be
              false, you can institute measurements to verify or refute that
              logic.

              In response to the earlier two dubious heuristics, I have
              heard anecdotes where much of the traceability was ditched
              as not being worthwhile after people investigated how often
              the various traces were used. Processes that describe
              not the software development process itself, but how that
              process is tailored for individual projects, have been
              written up and passed audits. Thus the actual software
              development process itself does not need to be written
              down.


              Paul Oldfield
              www.aptprocess.com
            • Ron Jeffries
              ... Would you stop at XP practices on your path to CMM Level Whatever, if XP practices were enough to get you to that level? Ron Jeffries www.XProgramming.com
              Message 6 of 21 , Mar 28, 2004
              • 0 Attachment
                On Sunday, March 28, 2004, at 12:49:41 PM, chapmanstick2002 wrote:

                > I don't fully understand the question: "If XP were the most
                > appropriate process, would your efforts result in XP?" I can sort
                > of see what you're getting at but not fully, in the context of CMM.

                Would you stop at XP practices on your path to CMM Level Whatever, if XP
                practices were enough to get you to that level?

                Ron Jeffries
                www.XProgramming.com
                Yesterday's code should be as good as we could make it yesterday.
                The fact that we know more today, and are more capable today,
                is good news about today, not bad news about yesterday.
              • chapmanstick2002
                ... your ... be industry ... lie. ... started ... improvements? ... The way through for SPI really depends on the environment the company is in - in some
                Message 7 of 21 , Mar 28, 2004
                • 0 Attachment
                  --- In extremeprogramming@yahoogroups.com, "Jeff Grigg"
                  <jeffgrigg@c...> wrote:
                  > --- PaulOldfield1@c... wrote:
                  > > It depends why your company is pursuing CMMI and their
                  > > attitude as they go about it. [...]
                  > >
                  > > The problems arise when CMM/I are pursued with a "tick the
                  > > box" mentality rather than a genuine desire to improve
                  > > process, [...]
                  >
                  > > It's worth asking the person running the SPI effort
                  > > "If XP were the most appropriate process, would your
                  > > efforts result in XP?"
                  >
                  > My concern would be that the person running the SPI effort would
                  > smile and say, "Why yes, of course it would." ...and given that
                  your
                  > concerns had been successfully dismissed, go on to say, "Now, what
                  > are you doing to guarantee that all the requirements are correctly
                  > gathered and documented up-front -- as that's known to
                  be 'industry
                  > best practice.'"
                  >
                  > Such a direct pass/fail question strikes me as an invitation to
                  lie.
                  > _ _ _
                  >
                  > Further, suppose that a Software Process Improvement effort
                  started
                  > with waterfall and honestly and consistently worked to improve it
                  > over time. Would they end up at XP (or some similar agile
                  > process)? How could one get sufficient automated testing support
                  > for refactoring to be safe through small incremental
                  improvements?
                  > And even if they would, in theory, eventually get to XP, would you
                  > still be alive by then? ;->

                  The way through for SPI really depends on the environment the
                  company is in - in some environments more formality or ceremony is
                  necessary, and others, an agile approach is appropriate. My driver
                  for improvement is eliminating waste and doing it in a way that
                  makes sense - in some cases, that will mean XP-type practices; in
                  others, it will mean moving to something heavier with more
                  documentation flying around because the customer demands it, and/or
                  the team is spread over many offices.

                  I like Cockburn's two dimensional evaluation that he talks about for
                  Crystal - more people on the team and/or more damage from failure,
                  the more formal you need to be. I would either substitute or add
                  the distance between team members and between the team and customer
                  as another dimension. It fits my situation well.

                  SPI/CMM != waterfall automatically these days. I picked up Agile PM
                  with Scrum (MS Press) and in the back, the author relates a
                  discussion with Mark Paulk that appears to indicate that Scrum would
                  address many Level 2 and 3 KPAs...these references are increasing in
                  number, gradually...

                  cheers
                  will
                • Steven Gordon
                  Will, Is anyone doing CMM willing to stop at level 2 or 3, even if they are successfully developing good software? To go further, you have to add considerable
                  Message 8 of 21 , Mar 28, 2004
                  • 0 Attachment
                    Will,

                    Is anyone doing CMM willing to stop at level 2 or 3, even if they are successfully developing good software? To go further, you have to add considerable waste to the process just to collect auditable documentation, whether or not that extra weight ever leads to any real improvements in the software being produced or the cost of producing that software.

                    If you interested in eliminating waste, I would highly recommend Lean Software Development: An Agile Toolkit <http://www.poppendieck.com/ld.htm>. Besides presenting an excellent guide to eliminating waste effectively in the context of software development, the Poppendiecks present the case that a process that evolved to be successful on some software development project cannot be simply copied and applied to another project.

                    Each project, team, customer, and context is different enough that we have to apply the principles again to that project instead of just copying what worked on a previous project. While CMM has undeniable marketing value to customers who want to believe in repeatable processes for software development, I personally believe that repeatable processes for software development is an expensive, naive fairy tale that distracts us from providing maximum deliverable value to our customers on a project by project basis.

                    Steven Gordon
                    http://sf.asu.edu/


                    -----Original Message-----
                    From: chapmanstick2002 [mailto:willgough@...]
                    Sent: Sun 3/28/2004 5:04 PM
                    To: extremeprogramming@yahoogroups.com
                    Cc:
                    Subject: Re: [XP] cmm and agile?

                    --- In extremeprogramming@yahoogroups.com, "Jeff Grigg"
                    <jeffgrigg@c...> wrote:
                    > --- PaulOldfield1@c... wrote:
                    > > It depends why your company is pursuing CMMI and their
                    > > attitude as they go about it. [...]
                    > >
                    > > The problems arise when CMM/I are pursued with a "tick the
                    > > box" mentality rather than a genuine desire to improve
                    > > process, [...]
                    >
                    > > It's worth asking the person running the SPI effort
                    > > "If XP were the most appropriate process, would your
                    > > efforts result in XP?"
                    >
                    > My concern would be that the person running the SPI effort would
                    > smile and say, "Why yes, of course it would." ...and given that
                    your
                    > concerns had been successfully dismissed, go on to say, "Now, what
                    > are you doing to guarantee that all the requirements are correctly
                    > gathered and documented up-front -- as that's known to
                    be 'industry
                    > best practice.'"
                    >
                    > Such a direct pass/fail question strikes me as an invitation to
                    lie.
                    > _ _ _
                    >
                    > Further, suppose that a Software Process Improvement effort
                    started
                    > with waterfall and honestly and consistently worked to improve it
                    > over time. Would they end up at XP (or some similar agile
                    > process)? How could one get sufficient automated testing support
                    > for refactoring to be safe through small incremental
                    improvements?
                    > And even if they would, in theory, eventually get to XP, would you
                    > still be alive by then? ;->

                    The way through for SPI really depends on the environment the
                    company is in - in some environments more formality or ceremony is
                    necessary, and others, an agile approach is appropriate. My driver
                    for improvement is eliminating waste and doing it in a way that
                    makes sense - in some cases, that will mean XP-type practices; in
                    others, it will mean moving to something heavier with more
                    documentation flying around because the customer demands it, and/or
                    the team is spread over many offices.

                    I like Cockburn's two dimensional evaluation that he talks about for
                    Crystal - more people on the team and/or more damage from failure,
                    the more formal you need to be. I would either substitute or add
                    the distance between team members and between the team and customer
                    as another dimension. It fits my situation well.

                    SPI/CMM != waterfall automatically these days. I picked up Agile PM
                    with Scrum (MS Press) and in the back, the author relates a
                    discussion with Mark Paulk that appears to indicate that Scrum would
                    address many Level 2 and 3 KPAs...these references are increasing in
                    number, gradually...

                    cheers
                    will
                  • yahoogroups@jhrothjr.com
                    From: Steven Gordon To: extremeprogramming@yahoogroups.com
                    Message 9 of 21 , Mar 28, 2004
                    • 0 Attachment
                      From: "Steven Gordon" <sagordon.at.asu.edu@...>
                      To: "extremeprogramming@yahoogroups.com"
                      <extremeprogramming.at.yahoogroups.com@...>;
                      "willgough@..."
                      <willgough.at.nf.sympatico.ca@...>
                      Sent: Sunday, March 28, 2004 8:06 PM
                      Subject: RE: [XP] cmm and agile?


                      > Will,
                      >
                      > Is anyone doing CMM willing to stop at level 2 or 3, even if they are
                      successfully developing good software? To go further, you have to add
                      considerable waste to the process just to collect auditable documentation,
                      whether or not that extra weight ever leads to any real improvements in the
                      software being produced or the cost of producing that software.

                      I'm not at all certain that "considerable" is the right word. Our recent
                      discussion of requirements tracability showed that a number of lightweight
                      and automated adapations to the usual infrastructure would suffice. I also
                      don't know that the information gathered is useless for anything other than
                      sasisfying an audit. Probably, but I'd like to hear from someone who's
                      company has done it to satisfy government contracting requirements.

                      > If you interested in eliminating waste, I would highly recommend Lean
                      Software Development: An Agile Toolkit <http://www.poppendieck.com/ld.htm>.
                      Besides presenting an excellent guide to eliminating waste effectively in
                      the context of software development, the Poppendiecks present the case that
                      a process that evolved to be successful on some software development project
                      cannot be simply copied and applied to another project.

                      Lean Software Development is a very good book.

                      > Each project, team, customer, and context is different enough that we have
                      to apply the principles again to that project instead of just copying what
                      worked on a previous project. While CMM has undeniable marketing value to
                      customers who want to believe in repeatable processes for software
                      development, I personally believe that repeatable processes for software
                      development is an expensive, naive fairy tale that distracts us from
                      providing maximum deliverable value to our customers on a project by project
                      basis.

                      Your are, of course, refering to the 15 XP principles in chapter 8 of the
                      White Book?

                      John Roth
                      >
                      > Steven Gordon
                      > http://sf.asu.edu/
                      >
                      >
                      > -----Original Message-----
                      > From: chapmanstick2002 [mailto:willgough@...]
                      > Sent: Sun 3/28/2004 5:04 PM
                      > To: extremeprogramming@yahoogroups.com
                      > Cc:
                      > Subject: Re: [XP] cmm and agile?
                      >
                      > --- In extremeprogramming@yahoogroups.com, "Jeff Grigg"
                      > <jeffgrigg@c...> wrote:
                      > > --- PaulOldfield1@c... wrote:
                      > > > It depends why your company is pursuing CMMI and their
                      > > > attitude as they go about it. [...]
                      > > >
                      > > > The problems arise when CMM/I are pursued with a "tick the
                      > > > box" mentality rather than a genuine desire to improve
                      > > > process, [...]
                      > >
                      > > > It's worth asking the person running the SPI effort
                      > > > "If XP were the most appropriate process, would your
                      > > > efforts result in XP?"
                      > >
                      > > My concern would be that the person running the SPI effort would
                      > > smile and say, "Why yes, of course it would." ...and given that
                      > your
                      > > concerns had been successfully dismissed, go on to say, "Now, what
                      > > are you doing to guarantee that all the requirements are correctly
                      > > gathered and documented up-front -- as that's known to
                      > be 'industry
                      > > best practice.'"
                      > >
                      > > Such a direct pass/fail question strikes me as an invitation to
                      > lie.
                      > > _ _ _
                      > >
                      > > Further, suppose that a Software Process Improvement effort
                      > started
                      > > with waterfall and honestly and consistently worked to improve it
                      > > over time. Would they end up at XP (or some similar agile
                      > > process)? How could one get sufficient automated testing support
                      > > for refactoring to be safe through small incremental
                      > improvements?
                      > > And even if they would, in theory, eventually get to XP, would you
                      > > still be alive by then? ;->
                      >
                      > The way through for SPI really depends on the environment the
                      > company is in - in some environments more formality or ceremony is
                      > necessary, and others, an agile approach is appropriate. My driver
                      > for improvement is eliminating waste and doing it in a way that
                      > makes sense - in some cases, that will mean XP-type practices; in
                      > others, it will mean moving to something heavier with more
                      > documentation flying around because the customer demands it, and/or
                      > the team is spread over many offices.
                      >
                      > I like Cockburn's two dimensional evaluation that he talks about for
                      > Crystal - more people on the team and/or more damage from failure,
                      > the more formal you need to be. I would either substitute or add
                      > the distance between team members and between the team and customer
                      > as another dimension. It fits my situation well.
                      >
                      > SPI/CMM != waterfall automatically these days. I picked up Agile PM
                      > with Scrum (MS Press) and in the back, the author relates a
                      > discussion with Mark Paulk that appears to indicate that Scrum would
                      > address many Level 2 and 3 KPAs...these references are increasing in
                      > number, gradually...
                      >
                      > cheers
                      > will
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      > To Post a message, send it to: extremeprogramming@...
                      >
                      > To Unsubscribe, send a blank message to:
                      extremeprogramming-unsubscribe@...
                      >
                      > ad-free courtesy of objectmentor.com
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                      >
                    • jrb32002
                      ... Actually, it s an invitation to point out the invalid assumption: that documenting all the requirements up-front *together* is industry best practice . XP
                      Message 10 of 21 , Mar 29, 2004
                      • 0 Attachment
                        --- In extremeprogramming@yahoogroups.com, "Jeff Grigg"
                        <jeffgrigg@c...> wrote:
                        > My concern would be that the person running the SPI effort would
                        > smile and say, "Why yes, of course it would." ...and given that your
                        > concerns had been successfully dismissed, go on to say, "Now, what
                        > are you doing to guarantee that all the requirements are correctly
                        > gathered and documented up-front -- as that's known to be 'industry
                        > best practice.'"
                        >
                        > Such a direct pass/fail question strikes me as an invitation to lie.

                        Actually, it's an invitation to point out the invalid assumption:
                        that documenting all the requirements up-front *together* is
                        "industry best practice".

                        XP and lots of agile (and most waterfall trying to cope with
                        reality) uncover and communicate requirements, not as one chunk and
                        frozen forever, but over time.

                        There's also the imprecision of the phrase "industry best
                        practice". If it's whatever a substantial minority are doing to
                        succeed, then just about anything can be argued to be an "industry
                        best practice". If it's whatever some excellent and successful team
                        has done, it's been publicized and replicated (and success with the
                        replications publicized), then XP *is* an industry best practice.


                        I'm not yet ready to go after the underlying assumptions under
                        those assumptions, such as an external auditor is necessary to ensure
                        adherence to a process, which adherence by its very existence will
                        ensure customer value is delivered. In my section of the software
                        industry, this last assumption is both wildly invalid and toxic.

                        Joseph Beckenbach
                        lead XP tester, Eidogen Inc.
                      • Robert C. Martin
                        ... There is an implicit assumption lurking in this paragraph that XP is not formal. Indeed, I ve heard this argument made many different times by many
                        Message 11 of 21 , Mar 31, 2004
                        • 0 Attachment
                          > I like Cockburn's two dimensional evaluation that he talks about for
                          > Crystal - more people on the team and/or more damage from failure,
                          > the more formal you need to be. I would either substitute or add
                          > the distance between team members and between the team and customer
                          > as another dimension. It fits my situation well.
                          >

                          There is an implicit assumption lurking in this paragraph that XP is not
                          formal. Indeed, I've heard this argument made many different times by many
                          different people. They say that XP is informal; or XP is low ceremony.

                          I think they are wrong. I think XP is very formal and is high ceremony. It
                          is formal in that all the essential documents produced by XP are executable.
                          Requirements are documented as executable acceptance tests. Designs are
                          documented as executable unit tests. It is high ceremony because there are
                          certain things that must be done as a team every day, every week, and every
                          month. XP does not mean ad-hoc.

                          The that is as stake (the more damage from risk) the more you need to write
                          your unit tests first, write your acceptance tests first, and work in very
                          short cycles with lots of stakeholder feedback. The more people you have on
                          the team, the more you need communication, tests, short cycles, and lots of
                          feedback.
                        • Ron Jeffries
                          ... Yes. I m not sure that I d use the word formal for what I m about to say. If I were doing some kind of life-critical or $-critical project, I could
                          Message 12 of 21 , Mar 31, 2004
                          • 0 Attachment
                            On Thursday, April 1, 2004, at 1:25:36 AM, Robert C. Martin wrote:



                            >> I like Cockburn's two dimensional evaluation that he talks about for
                            >> Crystal - more people on the team and/or more damage from failure,
                            >> the more formal you need to be. I would either substitute or add
                            >> the distance between team members and between the team and customer
                            >> as another dimension. It fits my situation well.
                            >>

                            > There is an implicit assumption lurking in this paragraph that XP is not
                            > formal. Indeed, I've heard this argument made many different times by many
                            > different people. They say that XP is informal; or XP is low ceremony.

                            > I think they are wrong. I think XP is very formal and is high ceremony. It
                            > is formal in that all the essential documents produced by XP are executable.
                            > Requirements are documented as executable acceptance tests. Designs are
                            > documented as executable unit tests. It is high ceremony because there are
                            > certain things that must be done as a team every day, every week, and every
                            > month. XP does not mean ad-hoc.

                            > The that is as stake (the more damage from risk) the more you need to write
                            > your unit tests first, write your acceptance tests first, and work in very
                            > short cycles with lots of stakeholder feedback. The more people you have on
                            > the team, the more you need communication, tests, short cycles, and lots of
                            > feedback.

                            Yes. I'm not sure that I'd use the word "formal" for what I'm about to say.

                            If I were doing some kind of life-critical or $-critical project, I could
                            imagine adding more process elements, such as code inspections, design
                            reviews, and such.

                            I would not be inclined, unless external circumstances required it, to do
                            much documentation of those things, but I probably would, for my own
                            comfort, want some kind of tracking to let me be sure that everything that
                            should go through some process element, did go through it.

                            I'm not at all convinced that requirements tracing, big design documents,
                            keeping documents up to date, and the usual high ceremony claptrap, somehow
                            help with -critical projects. I'd certainly want to have people on board
                            who had experiences with -critical projects, and I'd want to hear and
                            understand their views on what should be done.

                            So, would I do more if my life depended on it? Sure. But perhaps not what
                            CMMI or RUP thinks I should do ...

                            UB, et al: would you do more stuff on such a project? And if so ... what?

                            Ron Jeffries
                            www.XProgramming.com
                            I'm giving the best advice I have. You get to decide whether it's true for you.
                          • Robert C. Martin
                            ... On a life critical project I d * shorten the cycles to a week -- possibly less. (I note that the Mercury Capsule software was written in cycles of one
                            Message 13 of 21 , Apr 1, 2004
                            • 0 Attachment
                              >
                              > UB, et al: would you do more stuff on such a project? And if so ... what?

                              On a life critical project I'd

                              * shorten the cycles to a week -- possibly less. (I note that the Mercury
                              Capsule software was written in cycles of one half day IIRC) I wouldn't want
                              the process or the code to go open-loop for very long because the most
                              damage is done when feedback is at it's lowest.

                              * I'd be an absolute tyrant about unit testing and acceptance testing.
                              Unit tests and acceptance tests would be written first; and no production
                              code would be written unless it was to make a failing unit test pass in
                              pursuit of making a failing acceptance test pass.

                              * I'd be very strict about pairing. It's harder for two people to break
                              the rules than it is for one.

                              * I'd use a code coverage tool (like clover) and insert it into the build
                              process. High test coverage would become a criterion of a successful build.
                              (I don't know what numbers I'd use at this point but since life is at stake
                              they'd be very stringent. On the order of 99% statement and branch coverage
                              most likely.)

                              * I'd use a dependency tracking tool (like Jdepend) and insert it into the
                              build process. Appropriate package dependencies would become a criterion of
                              a successful build. Package dependencies would not be added without
                              consensus of the team.

                              * I'd run the build process every time a module was checked in. I'd raise
                              holy hell each time the build failed. A build fails if any checked in unit
                              test fails, or any previously passing acceptance test fails, or the test
                              coverage criterion fails, or the dependency tracking fails.

                              * I'd use the dependency tracking tools, and complexity measurement tools,
                              and most importantly the advice of the team to identify "modules in
                              trouble". We'd target these modules for special cleanup efforts.

                              * I'd set up a comprehensive system test plan that included manual test
                              scripts, random usage tests, etc. I'd regularly look over those manual
                              scripts to find thins that I could automate. In this case I would not
                              remove them from the manual test, I'd just add them to the automatic suite.
                              Since lives are at stake, we need human verification not just computer
                              verification. On the other hand, I want those human verifiers to find no
                              problems at all. (Unless I seed a problem to check their efficacy.)

                              * I would document and archive the result of each build, each manual test,
                              each iteration plan, each standup meeting, etc. I'd leave an audit trail
                              that would keep the lawyers happy, and that would allow the customers who
                              are putting their lives in my hands to content themselves that everything
                              that should and can be done has been done.

                              This is a short list. There's certainly be more. But I think everyone
                              get's the idea.

                              I could make the list even shorter simply by saying: "I'd turn all the
                              damned knobs up to 12."

                              -----
                              Robert C. Martin (Uncle Bob)
                              Object Mentor Inc.
                              unclebob@...
                              800-338-6716
                            • Jeff Grigg
                              ... ...like maybe automated defect seeding, to test the tests: http://jester.sourceforge.net/
                              Message 14 of 21 , Apr 1, 2004
                              • 0 Attachment
                                --- "Robert C. Martin" <UncleBob@o...> wrote:
                                > [...] On the other hand, I want those human verifiers
                                > to find no problems at all. (Unless I seed a problem
                                > to check their efficacy.)
                                > [...]
                                > This is a short list. There's certainly be more. But
                                > I think everyone get's the idea.

                                ...like maybe automated defect seeding, to test the tests:

                                http://jester.sourceforge.net/
                              • Alleman, Glen B.
                                Robert, XP is certainty low ceremony when compared to high ceremony CMMI processes. The formality of XP is a value judgment though. Compared to our projects
                                Message 15 of 21 , Apr 1, 2004
                                • 0 Attachment
                                  Robert,

                                  XP is certainty low ceremony when compared to high ceremony CMMI
                                  processes. The formality of XP is a value judgment though. Compared to
                                  our projects that use CMMI assessed process the formality of XP is very
                                  low. A 64 page configuration management guide with check list as the
                                  working document for the Change Control Board weekly meeting would not
                                  likely be found on an XP project.

                                  In the high ceremony, high formality projects we work on, the format and
                                  media for the design is not defined by the team it is defined by the
                                  procurement regulations as a CDRL to the customer and their auditors.

                                  I've come to understand (and use) the fundamental differences between XP
                                  and not-XP is that the agile processes used on the project originate
                                  within the project. On not-agile projects the processes originate
                                  external to the project, either through contractual, regulatory, or
                                  policy means.

                                  An important Jack Welch quote that hangs in our common area is...

                                  "Bureaucracy protects the organization from the incompetent."

                                  Glen B. Alleman


                                  -----Original Message-----
                                  From: Robert C. Martin
                                  Subject: RE: [XP] cmm and agile?

                                  > I like Cockburn's two dimensional evaluation that he talks about for
                                  > Crystal - more people on the team and/or more damage from failure,
                                  > the more formal you need to be. I would either substitute or add
                                  > the distance between team members and between the team and customer
                                  > as another dimension. It fits my situation well.
                                  >

                                  There is an implicit assumption lurking in this paragraph that XP is not
                                  formal. Indeed, I've heard this argument made many different times by
                                  many
                                  different people. They say that XP is informal; or XP is low ceremony.

                                  I think they are wrong. I think XP is very formal and is high ceremony.
                                  It
                                  is formal in that all the essential documents produced by XP are
                                  executable.
                                  Requirements are documented as executable acceptance tests. Designs are
                                  documented as executable unit tests. It is high ceremony because there
                                  are
                                  certain things that must be done as a team every day, every week, and
                                  every
                                  month. XP does not mean ad-hoc.

                                  The that is as stake (the more damage from risk) the more you need to
                                  write
                                  your unit tests first, write your acceptance tests first, and work in
                                  very
                                  short cycles with lots of stakeholder feedback. The more people you
                                  have on
                                  the team, the more you need communication, tests, short cycles, and lots
                                  of
                                  feedback.
                                • Robert C. Martin
                                  ... Robert C. Martin (Uncle Bob) Object Mentor Inc. unclebob@objectmentor.com 800-338-6716 ... That may be true. Would you expect to find executable
                                  Message 16 of 21 , Apr 1, 2004
                                  • 0 Attachment
                                    -----
                                    Robert C. Martin (Uncle Bob)
                                    Object Mentor Inc.
                                    unclebob@...
                                    800-338-6716


                                    > -----Original Message-----
                                    > From: Alleman, Glen B. [mailto:glen.alleman@...]
                                    > Sent: Thursday, April 01, 2004 3:18 PM
                                    > To: extremeprogramming@yahoogroups.com
                                    > Subject: RE: [XP] cmm and agile?
                                    >
                                    >
                                    > Robert,
                                    >
                                    > XP is certainty low ceremony when compared to high ceremony CMMI
                                    > processes. The formality of XP is a value judgment though. Compared to
                                    > our projects that use CMMI assessed process the formality of XP is very
                                    > low. A 64 page configuration management guide with check list as the
                                    > working document for the Change Control Board weekly meeting would not
                                    > likely be found on an XP project.

                                    That may be true. Would you expect to find executable requirements
                                    documents in a CMMI project? It seems to me that both are formal, just
                                    about different things.
                                    >
                                    > An important Jack Welch quote that hangs in our common area is...
                                    >
                                    > "Bureaucracy protects the organization from the incompetent."

                                    There is a corollary to this quote:

                                    "Incompetence subjects the organization to bureaucracy."

                                    -----
                                    Robert C. Martin (Uncle Bob)
                                    Object Mentor Inc.
                                    unclebob@...
                                    800-338-6716
                                  • Tony Nassar
                                    ... Is Welch for or against? How could an employee take this other than as, We are justified in imposing layers of bureaucracy on you because we have to
                                    Message 17 of 21 , Apr 1, 2004
                                    • 0 Attachment
                                      > An important Jack Welch quote that hangs in our common area is...
                                      >
                                      > "Bureaucracy protects the organization from the incompetent."

                                      Is Welch for or against? How could an employee take this other than as, "We are justified in imposing layers of bureaucracy on you because we have to protect the company against your incompetence." Maybe I'm accentuating the negative, but if this is supposed to be a motivational slogan, why is it set against a presumption of incompetence?


                                      [Non-text portions of this message have been removed]
                                    • WILLIAMS Dominic
                                      ... Bureaucracy protects the incomptetent from the organization. Dominic Williams http://www.dominicwilliams.net
                                      Message 18 of 21 , Apr 1, 2004
                                      • 0 Attachment
                                        > An important Jack Welch quote that hangs in our common area is...
                                        >
                                        > "Bureaucracy protects the organization from the incompetent."

                                        Bureaucracy protects the incomptetent from the organization.

                                        Dominic Williams
                                        http://www.dominicwilliams.net

                                        ----
                                      • Jeff Grigg
                                        ... Bureaucracy protects the incompetent from the consequences of their own actions. And this is not a good thing. -- JeffGrigg
                                        Message 19 of 21 , Apr 2, 2004
                                        • 0 Attachment
                                          >> "Bureaucracy protects the organization from the incompetent."
                                          >> -- Jack Welch

                                          > "Bureaucracy protects the incompetent from the organization."
                                          > -- Dominic Williams

                                          "Bureaucracy protects the incompetent from the consequences
                                          of their own actions.
                                          "And this is not a good thing."
                                          -- JeffGrigg
                                        • Alleman, Glen B.
                                          Robert, ... very ... That may be true. Would you expect to find executable requirements documents in a CMMI project? It seems to me that both are formal,
                                          Message 20 of 21 , Apr 2, 2004
                                          • 0 Attachment
                                            Robert,

                                            > -----Original Message-----
                                            > From: Alleman, Glen B. [mailto:glen.alleman@...]
                                            > Subject: RE: [XP] cmm and agile?
                                            > Robert,
                                            >
                                            > XP is certainty low ceremony when compared to high ceremony CMMI
                                            > processes. The formality of XP is a value judgment though. Compared to
                                            > our projects that use CMMI assessed process the formality of XP is
                                            very
                                            > low. A 64 page configuration management guide with check list as the
                                            > working document for the Change Control Board weekly meeting would not
                                            > likely be found on an XP project.

                                            That may be true. Would you expect to find executable requirements
                                            documents in a CMMI project? It seems to me that both are formal, just
                                            about different things.

                                            [GBA] CMMI says little about "how" to do the requirements. If executable
                                            requirements also met the needs of the requirements elicitation process
                                            holders - Systems Program Office e.g. - then they would add value to the
                                            process.
                                            >
                                            > An important Jack Welch quote that hangs in our common area is...
                                            >
                                            > "Bureaucracy protects the organization from the incompetent."

                                            There is a corollary to this quote:

                                            "Incompetence subjects the organization to bureaucracy."

                                            [GBA] So true. It the spinning ying-yang symbol all over again. Welch's
                                            starting point was in incumbent organization, where he removed the
                                            bureaucracy to expose the incompetence. From there he (and his
                                            consulting staff) could easily identify the gaps in the process. In the
                                            absence of this bureaucracy "shield" the problems were masked.

                                            -----
                                            Robert C. Martin

                                            Glen B. Alleman
                                          • Alleman, Glen B.
                                            GE s approach: remove the bureaucracy and expose the gaps...fix the gaps and you don t need the bureaucracy. Glen B. Alleman ... From: Tony Nassar
                                            Message 21 of 21 , Apr 2, 2004
                                            • 0 Attachment
                                              GE's approach: remove the bureaucracy and expose the gaps...fix the gaps
                                              and you don't need the bureaucracy.

                                              Glen B. Alleman

                                              -----Original Message-----
                                              From: Tony Nassar [mailto:tnassar@...]
                                              Sent: Thursday, April 01, 2004 10:50 PM
                                              To: extremeprogramming@yahoogroups.com
                                              Subject: RE: [XP] cmm and agile?

                                              > An important Jack Welch quote that hangs in our common area is...
                                              > "Bureaucracy protects the organization from the incompetent."

                                              Is Welch for or against? How could an employee take this other than as,
                                              "We are justified in imposing layers of bureaucracy on you because we
                                              have to protect the company against your incompetence." Maybe I'm
                                              accentuating the negative, but if this is supposed to be a motivational
                                              slogan, why is it set against a presumption of incompetence?
                                            Your message has been successfully submitted and would be delivered to recipients shortly.