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

Re: [agile-testing] CMMI is a framework, and agile is the best practices for the development

Expand Messages
  • Phlip
    ... Can CMMI achieve Fail early or succeed ? Could a project run at Level 5, and not profit? -- Phlip http://c2.com/cgi/wiki?ZeekLand
    Message 1 of 10 , Aug 6, 2006
    View Source
    • 0 Attachment
      Steven Gordon wrote:

      > However, in practice there are lots of issues, including:
      > - the organizational motivations for doing each generally conflict
      > - supporting CMMI compliance auditing adds waste and overhead from an
      > agile point of view
      > - agile entails the improvement of each individual project's process

      Can CMMI achieve "Fail early or succeed"? Could a project run at Level
      5, and not profit?

      --
      Phlip
      http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
    • STEURS Stefan
      Whether CMMI and Agile practices are compatible or congruent is not really an issue. CMMI fits within organisations for which part of the deliverables
      Message 2 of 10 , Aug 6, 2006
      View Source
      • 0 Attachment
        Message
        Whether CMMI and Agile practices are "compatible" or "congruent" is not really an issue.  CMMI fits within organisations for which part of the deliverables they have is the development process they follow.  There are two keywords in this phrase.  One is "organisation" the other is "process".  Each organisation exits within a context and to some extent an organisation will be self-perpetuating.  The people in it develop a culture within which they will hire people that fit with that culture.  You can look at an organisation as an entity which will hapily continue to live as long as the circumstances within which it exists don't change too drastically.  Whether such an organisation uses a waterfall or agile development process isn't all too relevant.
         
        I think an organisation will define a process that fits with it's metabolistic rate.  Big organisations will usually develop low metabolism and long decision cycles.  They can afford copy-paste processes (best practices).  They even need waterfall to some extent to fit with their long reporting lines and deep hierarchy decision overheads.  It takes a long time to turn a big ship around.
         
        For me CMMI is then about trying to develop a process that allows a heavy organisation to achieve a reasonable efficiency.
         
        When the metabolistic rate of the organsation is high, we don't need these long reporting lines.  Small organisations can more easily afford this and agile will fit nicely most of the time.  CMMI might even slow such an organisation down in terms of evolution and productivity.
         
        It's just one of the ways I think about CMMI and best practices.  It's all within human nature and the way humans organise themselves.  Nothing wrong or right about it, just 'a' way to be.
         
        Regards, Stefan.
        -----Original Message-----
        From: agile-testing@yahoogroups.com [mailto:agile-testing@yahoogroups.com] On Behalf Of ahmed omran
        Sent: Friday 4 August 2006 08:56
        To: agile-testing@yahoogroups.com
        Subject: [agile-testing] CMMI is a framework, and agile is the best practices for the development

        CMMI is a framework, and agile is the best practices for the development

         

        Hi

        I would like to discuss the relation between CMMI and the agile methods from different point of view.

         

        I and others like to look at the CMMI as a  framework for the development process, and to look at the agile methods as a best practices for the process development.

        I can say that CMMI tell us what to do , while agile methodologies tell us how to.

        CMMI&Agile is not water and oil.. !?

         

         

        If we accept this idea then we can investigate the overlapping between the CMMI and the agile methods, and we can state each method (XP, Scrum, Crystal,…) whether they are heavy weighted with CMMI or they are more values will gained.

        We can discuss the details of CMMI (each KPA) from different point of view (especially from the agile principles side) to state how to use the hybrid concepts to get the high quality process, so we can get the high quality products.

         

        Now if any one have a real cases about CMMI&Agile, please attach them.

         

          - Rgards

        ____
        
        This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
        
        Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
        
        Any views expressed in this message are those of the sender.
        
        
      • Yosip
        ... Agree with you on this bullet, and would stress that there is nothing in the CMMI philosophy leading to such practice. The organizational motivation for
        Message 3 of 10 , Aug 7, 2006
        View Source
        • 0 Attachment
          Steven Gordon-2 wrote:
          >
          > Yes, there is no theoretical conflict between CMMI and agile
          > methodologies.
          >
          > However, in practice there are lots of issues, including:
          > - the organizational motivations for doing each generally conflict
          >

          Agree with you on this bullet, and would stress that there is nothing in the
          CMMI "philosophy" leading to such practice. The organizational motivation
          for both Agile and CMMI should be the same: Increase the value delivered to
          the customer.


          Steven Gordon-2 wrote:
          >
          > - supporting CMMI compliance auditing adds waste and overhead from an
          > agile point of view
          >

          You should do process compliance auditing only if it adds value too your
          customer (e.g. can reassure your customer that you will deliver a quality
          product on time). If they are happy with your past records or just your word
          on it, you don't need to go through the hassle of CMMI (ISO or any other)
          certification. But then, isn't it going for a "Scrum Master" certification
          also a "waste and overhead" from the Agile point of view?


          Steven Gordon-2 wrote:
          >
          > - agile entails the improvement of each individual project's process
          > during execution based on the team's repeated inspection and
          > adaptation, whereas it is my impression that CMMI-based process
          > improvement is focussed on improving a single process that is used
          > organization-wide based on a much less frequent inspection usually
          > conducted by a separate QA or process suborganization.
          >

          If you are improving your processes ad hoc during execution there is a big
          chance that you will be doing the same improvements again and again on every
          new project. Isn’t it a waste of time compared to documenting the lessons
          learned and reviewing them at the beginning of a new project? Also there is
          always an inherent risk in changing something when you don’t have a clear
          (documented and agreed) idea where you are and where you want to go. Very
          often you will come to the conclusion later that there was no reason for
          change at all. You need some kind of structure when you have more than two
          people engaged on the same project. Contrary to the popular opinion I think
          Agile methods are very structured and more rigorous than CMMI. I don’t think
          you will find anything in CMMI that will force you to have daily scrum
          meetings, develop your unit tests before your code or would prevent a large
          group of stakeholders (the chickens) to speak their mind.



          Steven Gordon-2 wrote:
          >
          > Many agilists bristle at the concept of "best practices", because we
          > believe that most practices are not best for every project at every
          > point in time. This goes back to giving each project team the right
          > and responsiblity for tailoring its own process on an ongoing basis
          > based on their circumstances and current priorities and problems.
          >

          Agree. Blindly implementing a process just because it was proclaimed a “best
          practice” is the worst an organization can do. But if the team is tailoring
          their process, where do they start from? In CMMI tailoring comes into the
          picture only on Level 3. There you are required to tailor the process for
          your current project (the defined process) from your organization’s
          (documented) standard process. And yes, you are required to also provide a
          rationale for your tailoring decisions.

          I don’t see how circumstances and current priorities could force the team to
          change their process on the ongoing basis. It looks to me more like panic
          behavior. Would you care to provide few examples?

          Thanks
          --
          View this message in context: http://www.nabble.com/CMMI-is-a-framework%2C-and-agile-is-the-best-practices-for-the-development-tf2059819.html#a5680855
          Sent from the Agile Testing forum at Nabble.com.
        • Brad Appleton
          I just blogged on this topic about a week ago and included a list of URLs/resources that discuss this issue. See
          Message 4 of 10 , Aug 7, 2006
          View Source
          • 0 Attachment
            I just blogged on this topic about a week ago and included a list of
            URLs/resources that discuss this issue.

            See
            <<http://blog.bradapp.net/2006/07/agile-cmmi-and-dancing-elephants.html>>

            ahmed omran wrote:
            >
            >
            > *CMMI is a framework, and agile is the best practices for the development *

            > I would like to discuss the relation between CMMI and the agile methods
            > from different point of view.
            >
            > I and others like to look at the CMMI as a framework for the
            > development process, and to look at the agile methods as a best
            > practices for the process development.
            >
            > I can say that CMMI tell us what to do , while agile methodologies tell
            > us how to.
            >
            > CMMI&Agile is not water and oil.. !?

            --
            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
          • Ron Jeffries
            Hello STEURS, Thank you for your note. On Monday, August 7, 2006, at 1:40:36 AM, ... As I understand CMM and CMMI and the SEI people I ve talked with,
            Message 5 of 10 , Aug 7, 2006
            View Source
            • 0 Attachment
              Hello STEURS,

              Thank you for your note. On Monday, August 7, 2006, at 1:40:36 AM,
              you wrote:

              > For me CMMI is then about trying to develop a process that allows a
              > heavy organisation to achieve a reasonable efficiency.

              As I understand CMM and CMMI and the SEI people I've talked with,
              efficiency is not a top priority. As far as I can tell, those people
              really do operate from a fundamental assumption that people cannot
              be trusted, will not work together to accomplish things, and that
              you have to tell them what to do.

              These assumptions can be well-founded, and the organization's
              cultural values can make them come true. A book I'm reading right
              now, /The Knowing-Doing Gap/ makes the point that business cultural
              and operational practices (such as individual assessments) can work
              strongly against people working well together. It becomes to your
              disadvantage to help me.

              Now it may be that these cultural characteristics of an organization
              can be boiled down into something like your (I would say) metabolic
              rate. I'm just thinking that the practices aren't focused on
              efficiency so much as certain assumptions about what people are and
              what they will do.
              >
              > When the metabolistic rate of the organsation is high, we don't need
              > these long reporting lines. Small organisations can more easily afford
              > this and agile will fit nicely most of the time. CMMI might even slow
              > such an organisation down in terms of evolution and productivity.

              CMMI can, I believe, be done in a lightweight fashion. CMM, which
              I've looked at in much more detail, certainly could be. It was
              reported at Agile 2006, though I wasn't able to verify this, that
              several XP organizations have been assessed at CMM Level 3. Again, I
              couldn't verify that, but I have spoken with an IBM CMM assessor
              after he took the XP Immersion course and he said that an XP team
              would, in his opinion, probably assess at L3.

              > It's just one of the ways I think about CMMI and best practices.
              > It's all within human nature and the way humans organise
              > themselves. Nothing wrong or right about it, just 'a' way to be.

              If we're talking about CMMI vs Agile, I guess I could agree that
              they are just a way to be, but I think a debate between an Agilista
              and a CMM proponent would bring out some assumptions about people
              that would be enlightening -- and irritating to some of us to hear
              how paternalistic the CMM people are.

              If we're talking about all the ways humans organize themselves, I
              would strongly disagree that there's nothing wrong or right about
              those ways. I agree that context matters. There do seem to be people
              who are not equipped to govern themselves. But their mas*H*H*H
              leaders aren't doing that good a job either. That, however, is
              probably off topic for this forum.

              Ron Jeffries
              www.XProgramming.com
              If you don't have the courage to say what you think,
              there isn't much use in thinking it, is there?
              --Thomas Jay Peckish II
            • STEURS Stefan
              People get irritated for the wrong reasons. A bit of what can I learn from you rather then an I know better . I have thoughts and opinions but these are
              Message 6 of 10 , Aug 7, 2006
              View Source
              • 0 Attachment
                People get irritated for the wrong reasons. A bit of "what can I learn
                from you" rather then an "I know better". I have thoughts and opinions
                but these are not necessarily "right" or "truth". It's from dialogue
                with people like you that I learn.

                If we would have the same "off topic" concern I can quote Bruce "War!
                What is it good for? Absolutely nothing."

                Regards, Stefan.


                -----Original Message-----
                From: agile-testing@yahoogroups.com
                [mailto:agile-testing@yahoogroups.com] On Behalf Of Ron Jeffries
                Sent: Monday 7 August 2006 10:50
                To: agile-testing@yahoogroups.com
                Subject: Re: [agile-testing] CMMI is a framework, and agile is the best
                practices for the development


                > It's just one of the ways I think about CMMI and best practices.
                > It's all within human nature and the way humans organise
                > themselves. Nothing wrong or right about it, just 'a' way to be.

                If we're talking about CMMI vs Agile, I guess I could agree that
                they are just a way to be, but I think a debate between an Agilista
                and a CMM proponent would bring out some assumptions about people
                that would be enlightening -- and irritating to some of us to hear
                how paternalistic the CMM people are.

                If we're talking about all the ways humans organize themselves, I
                would strongly disagree that there's nothing wrong or right about
                those ways. I agree that context matters. There do seem to be people
                who are not equipped to govern themselves. But their mas*H*H*H
                leaders aren't doing that good a job either. That, however, is
                probably off topic for this forum.

                Ron Jeffries
                www.XProgramming.com
                If you don't have the courage to say what you think,
                there isn't much use in thinking it, is there?
                --Thomas Jay Peckish II

                -> RIGHT!
                ____

                This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

                Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

                Any views expressed in this message are those of the sender.
              • Steven Gordon
                If you browse the archives of http://groups.yahoo.com/group/scrumdevelopment/, you will see numerous examples where a person will say their team is having such
                Message 7 of 10 , Aug 23, 2006
                View Source
                • 0 Attachment
                  If you browse the archives of
                  http://groups.yahoo.com/group/scrumdevelopment/, you will see numerous
                  examples where a person will say their team is having such and such a
                  problem. The experienced practitioners of Scrum will make a
                  surprisingly wide variety of suggestions as to what flaws in what
                  practices are possible causes of the issue observed and what
                  adjustments might help.

                  Example issues include decreases in velocity, increases in defects,
                  disengaged customers, duplicative code, untested code, ...

                  Because agile is not prescriptive, people are people, and there is a
                  limited number of hours to the work week, no two teams are likely to
                  follow an agile process exactly the same way. Especially when first
                  starting up, no team is going to become effective at all the practices
                  immediately, nor even be able to know for sure which practices to hone
                  first to have the greatest immediate payoff.

                  Therefore, it is built into Scrum and XP (and most, if not all of the
                  other agile methodologies) for the team to frequently examine the
                  feeback they are getting and identify the few biggest issues they are
                  facing. At the end of every iteration, the team should come to a
                  consensus on:
                  - a few small adjustments to make in what they are doing in order to
                  address the highest priority issues, such as:
                  * spending more (or less) time on writing tests,
                  * spending more (or less) time on breaking current stories smaller,
                  * spending more (or less) time on detailed tasking and time estimation,
                  * spending more (or less) time on looking at future stories,
                  * doing more (or less) group design meetings,
                  * doing more (or less) technical documentation,
                  * doing more (or less) pair programming,
                  * doing more (or less) code reviews,
                  * writing tests sooner in each iteration,
                  * doing more (or less) manual testing,
                  * adding certain functionality to the continuous integration scripts,
                  * quit (or start) doing purely technical stories,
                  * quit (or start) doing spikes,
                  * quit (or start) working overtime,
                  * start committing to do more (or less) work in each iteration, ...
                  - and how to determine within a week or two if those adjustments made
                  things better or worse.

                  I am not talking about radical changes, just a series of small
                  adjustments and changes in emphasis. Of course, given different
                  personalities, customer priorities and team dynamics, the cumulative
                  small adjustments made by each team can create somewhat different
                  processes over a period of time. Lessons learned should certainly be
                  shared, and teams should certainly look at the adjustments other teams
                  are making, but different variations can be expected to work better
                  for different people in projects with different priorities and
                  challenges.

                  Steve

                  On 8/7/06, Yosip <yosip_55@...> wrote:
                  >
                  > Steven Gordon-2 wrote:
                  > >
                  > > Yes, there is no theoretical conflict between CMMI and agile
                  > > methodologies.
                  > >
                  > > However, in practice there are lots of issues, including:
                  > > - the organizational motivations for doing each generally conflict
                  > >
                  >
                  > Agree with you on this bullet, and would stress that there is nothing in
                  > the
                  > CMMI "philosophy" leading to such practice. The organizational motivation
                  > for both Agile and CMMI should be the same: Increase the value delivered to
                  > the customer.
                  >
                  > Steven Gordon-2 wrote:
                  > >
                  > > - supporting CMMI compliance auditing adds waste and overhead from an
                  > > agile point of view
                  > >
                  >
                  > You should do process compliance auditing only if it adds value too your
                  > customer (e.g. can reassure your customer that you will deliver a quality
                  > product on time). If they are happy with your past records or just your
                  > word
                  > on it, you don't need to go through the hassle of CMMI (ISO or any other)
                  > certification. But then, isn't it going for a "Scrum Master" certification
                  > also a "waste and overhead" from the Agile point of view?
                  >
                  > Steven Gordon-2 wrote:
                  > >
                  > > - agile entails the improvement of each individual project's process
                  > > during execution based on the team's repeated inspection and
                  > > adaptation, whereas it is my impression that CMMI-based process
                  > > improvement is focussed on improving a single process that is used
                  > > organization-wide based on a much less frequent inspection usually
                  > > conducted by a separate QA or process suborganization.
                  > >
                  >
                  > If you are improving your processes ad hoc during execution there is a big
                  > chance that you will be doing the same improvements again and again on
                  > every
                  > new project. Isn't it a waste of time compared to documenting the lessons
                  > learned and reviewing them at the beginning of a new project? Also there is
                  > always an inherent risk in changing something when you don't have a clear
                  > (documented and agreed) idea where you are and where you want to go. Very
                  > often you will come to the conclusion later that there was no reason for
                  > change at all. You need some kind of structure when you have more than two
                  > people engaged on the same project. Contrary to the popular opinion I think
                  > Agile methods are very structured and more rigorous than CMMI. I don't
                  > think
                  > you will find anything in CMMI that will force you to have daily scrum
                  > meetings, develop your unit tests before your code or would prevent a large
                  > group of stakeholders (the chickens) to speak their mind.
                  >
                  > Steven Gordon-2 wrote:
                  > >
                  > > Many agilists bristle at the concept of "best practices", because we
                  > > believe that most practices are not best for every project at every
                  > > point in time. This goes back to giving each project team the right
                  > > and responsiblity for tailoring its own process on an ongoing basis
                  > > based on their circumstances and current priorities and problems.
                  > >
                  >
                  > Agree. Blindly implementing a process just because it was proclaimed a
                  > "best
                  > practice" is the worst an organization can do. But if the team is tailoring
                  > their process, where do they start from? In CMMI tailoring comes into the
                  > picture only on Level 3. There you are required to tailor the process for
                  > your current project (the defined process) from your organization's
                  > (documented) standard process. And yes, you are required to also provide a
                  > rationale for your tailoring decisions.
                  >
                  > I don't see how circumstances and current priorities could force the team
                  > to
                  > change their process on the ongoing basis. It looks to me more like panic
                  > behavior. Would you care to provide few examples?
                  >
                  > Thanks
                  > --
                  > View this message in context:
                  > http://www.nabble.com/CMMI-is-a-framework%2C-and-agile-is-the-best-practices-for-the-development-tf2059819.html#a5680855
                  > Sent from the Agile Testing forum at Nabble.com.
                  >
                  >
                • Ron Jeffries
                  Hello Steven, thanks for writing. On Thursday, August 24, 2006, at ... I can think of a whole nother list that could have profited from this same email of
                  Message 8 of 10 , Aug 24, 2006
                  View Source
                  • 0 Attachment
                    Hello Steven, thanks for writing. On Thursday, August 24, 2006, at
                    12:09:01 AM, you wrote:

                    > Of course, given different
                    > personalities, customer priorities and team dynamics, the cumulative
                    > small adjustments made by each team can create somewhat different
                    > processes over a period of time.

                    I can think of a whole 'nother list that could have profited from
                    this same email of yours ...

                    Ron Jeffries
                    www.XProgramming.com
                    Steering is more important than speed,
                    in driving and in software development.
                  Your message has been successfully submitted and would be delivered to recipients shortly.