Agile or CMMI: Why Not Embrace Both!

[Heba Hosny-2]

Hi all,

I was wondering if Agile &  CMMi can be merged in some way, I'm going to
attend a conference that highlight this but first I'd like to know more of
your viewpoints.

I found that <http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm>
about
this topic.

Waiting for your replies,

--
All the best,
Heba Hosny
-----------------------
Never test the depth of a river with both feet

[chrs_mcmhn]

I'm too lazy to look up the references, but there's a generally accepted position that any reasonable agile process will be at least CMM Level 3 compliant.  

There is a less generally-accepted position that pursuing CMM Level 4 and 5 don't provide much benefit except in certain very rare cases.

I'm sure google will help you out given these pointers.

I see less and less attention paid to CMM/Six Sigma/ISO9000 from the agile community.  Slavishly following any of them simply becomes damage to be routed around.  See the Fishing Maturity Model.



--- In agile-testing@..., Heba Hosny <heba.hosny@...> wrote:

>
> Hi all,
>
> I was wondering if Agile &  CMMi can be merged in some way, I'm going to
> attend a conference that highlight this but first I'd like to know more of
> your viewpoints.
>
> I found that <http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm>
> about
> this topic.
>
> Waiting for your replies,
>
> --
> All the best,
> Heba Hosny
> -----------------------
> Never test the depth of a river with both feet
>

[Lisa Crispin-2]

Google Mark Paulk, he has written in the past about Agile (or XP) and CMMI.

There's nothing incompatible between agile and any of the quality models.
Coordinate with the folks in your company that deal with the quality model,
and you should be able to work it all out. I've talked to more ISO shops
that do agile than CMMI, but it's all the same kinda thing.
-- Lisa

On Thu, Oct 29, 2009 at 6:51 PM, chrs_mcmhn
<christopher.mcmahon@...>wrote:

>
>
>
>
> I'm too lazy to look up the references, but there's a generally accepted
> position that any reasonable agile process will be at least CMM Level 3
> compliant.
>
> There is a less generally-accepted position that pursuing CMM Level 4 and 5
> don't provide much benefit except in certain very rare cases.
>
> I'm sure google will help you out given these pointers.
>
> I see less and less attention paid to CMM/Six Sigma/ISO9000 from the agile
> community. Slavishly following any of them simply becomes damage to be
> routed around. See the Fishing Maturity Model.
>
> --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> Heba Hosny <heba.hosny@...> wrote:
> >
> > Hi all,
> >
> > I was wondering if Agile & CMMi can be merged in some way, I'm going to
> > attend a conference that highlight this but first I'd like to know more
> of
> > your viewpoints.
> >
> > I found that <
> http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm>
>
> > about
> > this topic.
> >
> > Waiting for your replies,
> >
> > --
> > All the best,
> > Heba Hosny
> > -----------------------
> > Never test the depth of a river with both feet
> >
>
>  
>

--
Lisa Crispin
Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
and Agile Teams_ (Addison-Wesley 2009)
http://lisacrispin.com

[wgyouree]

Heba,

I read the paper you linked to and I've studied CMMI and Agile for awhile now, so maybe I can help shed some light. There is no problem merging CMMI and Agile because CMMI is a model and not a process in of itself. It is really intended as a set of goals and recommended practices towards achieving those goals. The main point of CMMI is that you should have a standardized process in your organization which is measured and improved over time, and that can be adapted to specific projects / teams. Agile is a set of processes typically designed for small / medium sized teams. You can implement Agile processes in the context of an organization which is using the CMMI model to guide its process improvement efforts. In fact, by implementing the CMMI model, an organization may well be guided by the practices towards using Agile processes such as XP and Scrum for projects or sets of projects. It would then also collect metrics during the course of the projects and then analyze the results and make changes to the implementations of Agile processes it was using. And there are plenty of ways to collect pertinent metrics without imposing lengthy forms or reviews on the development teams. The reason for the metrics is to detect what is working and what isn't, so that the process can be improved over time.

In short, CMMI is a model meant to help organizations adopt and improve processes. Agile is a set of processes designed to rapidly produce reliable software that meets the customers needs. Much of the misunderstanding with CMMI is that people think that it is a standard or a process itself, and that is never what it was meant to be.

- W. Greg Youree

--- In agile-testing@..., Heba Hosny <heba.hosny@...> wrote:

>
> Hi all,
>
> I was wondering if Agile &  CMMi can be merged in some way, I'm going to
> attend a conference that highlight this but first I'd like to know more of
> your viewpoints.
>
> I found that <http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm>
> about
> this topic.
>
> Waiting for your replies,
>
> --
> All the best,
> Heba Hosny
> -----------------------
> Never test the depth of a river with both feet
>

[Matthew-103]

--- In agile-testing@..., Lisa Crispin <lisa.crispin@...> wrote:
>
>
> There's nothing incompatible between agile and
> any of the quality models.  Coordinate with the
> folks in your company that deal with the quality model,
> and you should be able to work it all out. I've talked
> to more ISO shops that do agile than CMMI, but it's
> all the same kinda thing.
> -- Lisa

At the lower levels, CMMI says "document everything."  At the higher levels, it says "measure everything."

There are significant issues in cognitive science and knowledge work with trying to document everything(1).  There are significant behavioral, social, and construct validity issues with trying to measure everything(2,3).

The CMMI also fails to deal with key dynamics of software development - most importantly, the value of rapid feedback.  While reviewing every "work product" is constantly mentioned, the idea to get to working software quickly really isn't a core value of the model.

The folks at the SEI respond to these problems, for the most part, by ignoring them.  Search the SEI website for "dysfunction" and you'll get all of two hits - critical issues in software measurement.  They are not responded to.

Moreover, the CMMI documents themselves were poorly written. You can tell this OBJECTIVELY, with metrics, by evaluating the Flesch-Kincaid readability score of the documents(4).

They generally score so high as to be incomprehensible.  This is not my /opinion/; it is repeatable experiment.  I've got /metrics/.

What you left with, after all that, is the fishing maturity model:

http://blogs.stpcollaborative.com/matt/2009/10/08/the-fishing-maturity-model/

Bottom Line: If you must do CMMI, I would consider it a wasteful-but-required process, in the Lean sense.


Regards,

--heusser
blog: http://blogs.stpcollaborative.com/matt
References:

(1) - "The Social Life of Information" - http://www.amazon.com/gp/product/1578517087?ie=UTF8&tag=heusseronlead-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1578517087

(2) - "Software Engineering Metrics: What do they measure and how do we know?" Kaner and Bond - http://www.kaner.com/pdfs/metrics2004.pdf

(3) - "Measuring and Managing Performance in Organizations", Robert Austin - http://www.amazon.com/gp/product/0932633366?ie=UTF8&tag=heusseronlead-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0932633366

(4) - http://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readability_test 

[Matthew-103]

I've corrected my opinion of the subject line.

--heusser

[Steven Gordon-2]

This is one of the few times that I totally agree with Matthew.

On Fri, Oct 30, 2009 at 5:29 AM, Matthew <matt.heusser@...> wrote:

>
>
> --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> Lisa Crispin <lisa.crispin@...> wrote:
> >
> >
> > There's nothing incompatible between agile and
> > any of the quality models. Coordinate with the
> > folks in your company that deal with the quality model,
> > and you should be able to work it all out. I've talked
> > to more ISO shops that do agile than CMMI, but it's
> > all the same kinda thing.
> > -- Lisa
>
> At the lower levels, CMMI says "document everything." At the higher levels,
> it says "measure everything."
>
> There are significant issues in cognitive science and knowledge work with
> trying to document everything(1). There are significant behavioral, social,
> and construct validity issues with trying to measure everything(2,3).
>
> The CMMI also fails to deal with key dynamics of software development -
> most importantly, the value of rapid feedback. While reviewing every "work
> product" is constantly mentioned, the idea to get to working software
> quickly really isn't a core value of the model.
>
> The folks at the SEI respond to these problems, for the most part, by
> ignoring them. Search the SEI website for "dysfunction" and you'll get all
> of two hits - critical issues in software measurement. They are not
> responded to.
>
> Moreover, the CMMI documents themselves were poorly written. You can tell
> this OBJECTIVELY, with metrics, by evaluating the Flesch-Kincaid readability
> score of the documents(4).
>
> They generally score so high as to be incomprehensible. This is not my
> /opinion/; it is repeatable experiment. I've got /metrics/.
>
> What you left with, after all that, is the fishing maturity model:
>
>
> http://blogs.stpcollaborative.com/matt/2009/10/08/the-fishing-maturity-model/
>
> Bottom Line: If you must do CMMI, I would consider it a
> wasteful-but-required process, in the Lean sense.
>
> Regards,
>
> --heusser
> blog: http://blogs.stpcollaborative.com/matt
> References:
>
> (1) - "The Social Life of Information" -
> http://www.amazon.com/gp/product/1578517087?ie=UTF8&tag=heusseronlead-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1578517087
>
> (2) - "Software Engineering Metrics: What do they measure and how do we
> know?" Kaner and Bond - http://www.kaner.com/pdfs/metrics2004.pdf
>
> (3) - "Measuring and Managing Performance in Organizations", Robert Austin
> -
> http://www.amazon.com/gp/product/0932633366?ie=UTF8&tag=heusseronlead-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0932633366
>
> (4) - http://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readability_test
>
>  
>

[Lisa Crispin-2]

Well, I wasn't saying I was a *fan* of any of these quality models, I
totally agree with you.
-- Lisa

On Fri, Oct 30, 2009 at 8:29 AM, Matthew <matt.heusser@...> wrote:

>
>
> --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> Lisa Crispin <lisa.crispin@...> wrote:
> >
> >
> > There's nothing incompatible between agile and
> > any of the quality models. Coordinate with the
> > folks in your company that deal with the quality model,
> > and you should be able to work it all out. I've talked
> > to more ISO shops that do agile than CMMI, but it's
> > all the same kinda thing.
> > -- Lisa
>
> At the lower levels, CMMI says "document everything." At the higher levels,
> it says "measure everything."
>
> There are significant issues in cognitive science and knowledge work with
> trying to document everything(1). There are significant behavioral, social,
> and construct validity issues with trying to measure everything(2,3).
>
> The CMMI also fails to deal with key dynamics of software development -
> most importantly, the value of rapid feedback. While reviewing every "work
> product" is constantly mentioned, the idea to get to working software
> quickly really isn't a core value of the model.
>
> The folks at the SEI respond to these problems, for the most part, by
> ignoring them. Search the SEI website for "dysfunction" and you'll get all
> of two hits - critical issues in software measurement. They are not
> responded to.
>
> Moreover, the CMMI documents themselves were poorly written. You can tell
> this OBJECTIVELY, with metrics, by evaluating the Flesch-Kincaid readability
> score of the documents(4).
>
> They generally score so high as to be incomprehensible. This is not my
> /opinion/; it is repeatable experiment. I've got /metrics/.
>
> What you left with, after all that, is the fishing maturity model:
>
>
> http://blogs.stpcollaborative.com/matt/2009/10/08/the-fishing-maturity-model/
>
> Bottom Line: If you must do CMMI, I would consider it a
> wasteful-but-required process, in the Lean sense.
>
> Regards,
>
> --heusser
> blog: http://blogs.stpcollaborative.com/matt
> References:
>
> (1) - "The Social Life of Information" -
> http://www.amazon.com/gp/product/1578517087?ie=UTF8&tag=heusseronlead-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1578517087
>
> (2) - "Software Engineering Metrics: What do they measure and how do we
> know?" Kaner and Bond - http://www.kaner.com/pdfs/metrics2004.pdf
>
> (3) - "Measuring and Managing Performance in Organizations", Robert Austin
> -
> http://www.amazon.com/gp/product/0932633366?ie=UTF8&tag=heusseronlead-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0932633366
>
> (4) - http://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readability_test
>
>  
>

--
Lisa Crispin
Co-author with Janet Gregory, _Agile Testing: A Practical Guide for Testers
and Agile Teams_ (Addison-Wesley 2009)
http://lisacrispin.com

[ligerly]

There was a talk at Agile 09 on an highest CMMI Level 5 company that adopted
agile and improved quality throughput by a factor of 4!  mmm, evidently
there is a level 6 after all [grin]

Watts Humphrey seems to be recognizing the value of Agile as well, and he
was one of the key folk behind the CMMI.  CMM (and later CMMI) were created
to solve a problem at the time (Defence Dept project budget blowouts or
failures).  They never had testing as a measurable KPI, though.

Agile focuses on delivering completed bite size chunks, which as far as I
know never got a mention in CMMI.  Agile is also a lot more optimized for
groups to do local process improvement with minimal fuss.  In a large
organization, CMM may have a place, but it is very expensive..... It is a
great way of measuring the improvements that agile delivers!!!!!

Steve agrees with Matt, I agree with Steve, can you feel the love!!!! {grin}
cheers,
Erik

[chrs_mcmhn]

--- In agile-testing@..., erik petersen <ligerly@...> wrote:
>
> There was a talk at Agile 09 on an highest CMMI Level 5 company that adopted
> agile and improved quality throughput by a factor of 4!  mmm, evidently
> there is a level 6 after all [grin]

To me, this strongly suggests that CMM Level 5 is not correlated with quality at all.  

[Ciro Coelho]

I'd reccomend taking a look at Jeff Sutherland's opinion.

**http://jeffsutherland.com/scrum/2006/11/is-cmmi-worth-doing.html
http://jeffsutherland.com/scrum/SutherlandScrumCMMIHICSSPID498889.pdf

--
Ciro Coelho

On Mon, Nov 2, 2009 at 12:57 PM, chrs_mcmhn
<christopher.mcmahon@...>wrote:

>
>
>
>
> --- In agile-testing@... <agile-testing%40yahoogroups.com>,
> erik petersen <ligerly@...> wrote:
> >
> > There was a talk at Agile 09 on an highest CMMI Level 5 company that
> adopted
> > agile and improved quality throughput by a factor of 4! mmm, evidently
> > there is a level 6 after all [grin]
>
> To me, this strongly suggests that CMM Level 5 is not correlated with
> quality at all.
>
>  
>

[Matthew-103]

--- In agile-testing@..., "wgyouree" <wgyouree@...> wrote:
>There is no problem merging CMMI and Agile because CMMI
>is a model and not a process in of itself.
>

Yes, and in a previous post I made the point that it's not a particularly helpful model(*).  I do not believe those points have been addressed or debated in this forum.

I would welcome that debate.  

regards,


--heusser
(*) - I did compress a multi-hundred page document into two sentances; I would hope the audience would realize that some loss in involved when you do that.  What's azing is how /little/ loss is involved.

[Steven Gordon-2]

On Thu, Oct 29, 2009 at 4:28 PM, wgyouree <wgyouree@...> wrote:
>
>
>
> Heba,
>
> I read the paper you linked to and I've studied CMMI and Agile for awhile now, so maybe I can help shed some light. There is no problem merging CMMI and Agile because CMMI is a model and not a process in of itself. It is really intended as a set of goals and recommended practices towards achieving those goals. The main point of CMMI is that you should have a standardized process in your organization which is measured and improved over time, and that can be adapted to specific projects / teams. Agile is a set of processes typically designed for small / medium sized teams. You can implement Agile processes in the context of an organization which is using the CMMI model to guide its process improvement efforts. In fact, by implementing the CMMI model, an organization may well be guided by the practices towards using Agile processes such as XP and Scrum for projects or sets of projects. It would then also collect metrics during the course of the projects and then analyze the results and make changes to the implementations of Agile processes it was using. And there are plenty of ways to collect pertinent metrics without imposing lengthy forms or reviews on the development teams. The reason for the metrics is to detect what is working and what isn't, so that the process can be improved over time.
>
> In short, CMMI is a model meant to help organizations adopt and improve processes. Agile is a set of processes designed to rapidly produce reliable software that meets the customers needs. Much of the misunderstanding with CMMI is that people think that it is a standard or a process itself, and that is never what it was meant to be.

Software development is not manufacturing the same type of thing over
an over again.  Each project has different contexts which change over
time, guaranteeing that a standardized one-size-fits-all software
development process will be inefficient and inappropriate for many
projects.  This is why agile software development processes are not
prescriptive.  An agile software development process describes a
starting point for each team to continually adapt to their project as
the team learns what works for them in their particular dynamic
context.

This is not to say that what one team discovers to be highly useful
will not be useful for other teams.  Teams in the same or even
different organizations should indeed share ideas, but for agile to
work maximally each team has to take responsibility for its own path.
To fulfil this responsibility, each team has to continually identify
its own problems, potential solutions and metrics to measure the
effectiveness of those solutions.

Standardization in order to make the same improvements everywhere
removes the team being responsible for their own performance via
adapting their own process and will eventually kill agility as teams
conform to the organizational message that following the standard
process is safer and more highly valued that delivering working
software.

SteveG

>
> - W. Greg Youree
>

[Heba Hosny-2]

On Tue, Nov 3, 2009 at 7:33 PM, Steven Gordon <sgordonphd@...> wrote:

>
>
> On Thu, Oct 29, 2009 at 4:28 PM, wgyouree <wgyouree@...<wgyouree%40gmail.com>>
> wrote:
> >
> >
> >
> > Heba,
> >
> > I read the paper you linked to and I've studied CMMI and Agile for awhile
> now, so maybe I can help shed some light. There is no problem merging CMMI
> and Agile because CMMI is a model and not a process in of itself. It is
> really intended as a set of goals and recommended practices towards
> achieving those goals. The main point of CMMI is that you should have a
> standardized process in your organization which is measured and improved
> over time, and that can be adapted to specific projects / teams. Agile is a
> set of processes typically designed for small / medium sized teams. You can
> implement Agile processes in the context of an organization which is using
> the CMMI model to guide its process improvement efforts. In fact, by
> implementing the CMMI model, an organization may well be guided by the
> practices towards using Agile processes such as XP and Scrum for projects or
> sets of projects. It would then also collect metrics during the course of
> the projects and then analyze the results and make changes to the
> implementations of Agile processes it was using. And there are plenty of
> ways to collect pertinent metrics without imposing lengthy forms or reviews
> on the development teams. The reason for the metrics is to detect what is
> working and what isn't,so that the process can be improved over time.
>

>
>


>
>

>
>


> well, I was searching for those metrics to help out evaluating our
> progress, and what are those ways to collect them without imposing reviews
> on the development team which "that I actually do currently :) "
>





>


>  >
>

> In short, CMMI is a model meant to help organizations adopt and improve
> processes. Agile is a set of processes designed to rapidly produce reliable
> software that meets the customers needs. Much of the misunderstanding with
> CMMI is that people think that it is a standard or a process itself, and
> that is never what it was meant to be.
>
> Software development is not manufacturing the same type of thing over
> an over again. Each project has different contexts which change over
> time, guaranteeing that a standardized one-size-fits-all software
> development process will be inefficient and inappropriate for many
> projects. This is why agile software development processes are not
> prescriptive. An agile software development process describes a
> starting point for each team to continually adapt to their project as
> the team learns what works for them in their particular dynamic
> context.
>
> This is not to say that what one team discovers to be highly useful
> will not be useful for other teams. Teams in the same or even
> different organizations should indeed share ideas, but for agile to
> work maximally each team has to take responsibility for its own path.
> To fulfil this responsibility, each team has to continually identify
> its own problems, potential solutions and metrics to measure the
> effectiveness of those solutions.
>
> Standardization in order to make the same improvements everywhere
> removes the team being responsible for their own performance via
> adapting their own process and will eventually kill agility as teams
> conform to the organizational message that following the standard
> process is safer and more highly valued that delivering working
> software.
>

>
>

>
>


> But it has the benefit of letting all the teams got familiar with the
> organization standards, whenever he jumps from a project to another, he'll
> find no change in the steps he should follow, another point: how to evaluate
> all the projects on common standards as long as each follows his own
> process?
> --Heba
>


>
>


>
>


> SteveG
>
> >
> > - W. Greg Youree
> >
>
>  
>



--
All the best,
Heba Hosny
-----------------------
Never test the depth of a river with both feet

[wgyouree]

Heba,

The metrics you can use depend on the process your team is using and the programming language and environment you're using. But for an example, let's say you're using XP and Java. Then some good metrics would be, for each cycle, the number of story cards and corresponding task cards implemented, the number of test cases, the number of passing and failing tests, and code-coverage. Also, you can instrument your Java code and automatically collect metrics such as lines of code / number of statements, lack-of-cohesion of methods, inheritance tree depth, etc...

Keep in mind, CMMI is usually implemented from the top down and Agile is usually implemented from the bottom up. If you're in an organization using CMMI and you want to use Agile on a project, then you will probably need to champion its use by showing that it can be measured and that it is the best choice for your project/team. If you're using a more traditional process and want to transition to Agile, then I think it may be best to do it in steps. There is research on transitioning to Agile you can find on the net, and you can look for metrics that fit your Agile process and development environment.

- W. Greg Youree



--- In agile-testing@..., Heba Hosny <heba.hosny@...> wrote:

>
> On Tue, Nov 3, 2009 at 7:33 PM, Steven Gordon <sgordonphd@...> wrote:
>
> >
> >
> > On Thu, Oct 29, 2009 at 4:28 PM, wgyouree <wgyouree@...<wgyouree%40gmail.com>>
> > wrote:
> > >
> > >
> > >
> > > Heba,
> > >
> > > I read the paper you linked to and I've studied CMMI and Agile for awhile
> > now, so maybe I can help shed some light. There is no problem merging CMMI
> > and Agile because CMMI is a model and not a process in of itself. It is
> > really intended as a set of goals and recommended practices towards
> > achieving those goals. The main point of CMMI is that you should have a
> > standardized process in your organization which is measured and improved
> > over time, and that can be adapted to specific projects / teams. Agile is a
> > set of processes typically designed for small / medium sized teams. You can
> > implement Agile processes in the context of an organization which is using
> > the CMMI model to guide its process improvement efforts. In fact, by
> > implementing the CMMI model, an organization may well be guided by the
> > practices towards using Agile processes such as XP and Scrum for projects or
> > sets of projects. It would then also collect metrics during the course of
> > the projects and then analyze the results and make changes to the
> > implementations of Agile processes it was using. And there are plenty of
> > ways to collect pertinent metrics without imposing lengthy forms or reviews
> > on the development teams. The reason for the metrics is to detect what is
> > working and what isn't,so that the process can be improved over time.
> >
>
>
>
>
>
>
> >
> >
>
>
> >
> >
>
> >
> >
>
>
> > well, I was searching for those metrics to help out evaluating our
> > progress, and what are those ways to collect them without imposing reviews
> > on the development team which "that I actually do currently :) "
> >
>
>
>
>
>
> >
>
>
> >  >
> >
>
>
> > In short, CMMI is a model meant to help organizations adopt and improve
> > processes. Agile is a set of processes designed to rapidly produce reliable
> > software that meets the customers needs. Much of the misunderstanding with
> > CMMI is that people think that it is a standard or a process itself, and
> > that is never what it was meant to be.
> >
> > Software development is not manufacturing the same type of thing over
> > an over again. Each project has different contexts which change over
> > time, guaranteeing that a standardized one-size-fits-all software
> > development process will be inefficient and inappropriate for many
> > projects. This is why agile software development processes are not
> > prescriptive. An agile software development process describes a
> > starting point for each team to continually adapt to their project as
> > the team learns what works for them in their particular dynamic
> > context.
> >
> > This is not to say that what one team discovers to be highly useful
> > will not be useful for other teams. Teams in the same or even
> > different organizations should indeed share ideas, but for agile to
> > work maximally each team has to take responsibility for its own path.
> > To fulfil this responsibility, each team has to continually identify
> > its own problems, potential solutions and metrics to measure the
> > effectiveness of those solutions.
> >
> > Standardization in order to make the same improvements everywhere
> > removes the team being responsible for their own performance via
> > adapting their own process and will eventually kill agility as teams
> > conform to the organizational message that following the standard
> > process is safer and more highly valued that delivering working
> > software.
> >
>
>
>
>
> >
> >
>
> >
> >
>
>
> > But it has the benefit of letting all the teams got familiar with the
> > organization standards, whenever he jumps from a project to another, he'll
> > find no change in the steps he should follow, another point: how to evaluate
> > all the projects on common standards as long as each follows his own
> > process?
> > --Heba
> >
>
>
> >
> >
>
>
> >
> >
>
>
> > SteveG
> >
> > >
> > > - W. Greg Youree
> > >
> >
> >  
> >
>
>
>
> --
> All the best,
> Heba Hosny
> -----------------------
> Never test the depth of a river with both feet
>

[Matthew-103]

>But it has the benefit of letting all the teams got familiar
>with the organization standards, whenever he jumps from a
>project to another ...
>

Look. I like a good debate.  To some extent, I value the tussles with Steve Gordon or Ron Jeffries.   While I may disagree with them on a thing or two, I respect that they have actually developed working software - that the methods they talk about, they've, well ... done.

This idea that we need corporate-imposed(*) standards is a different thing entirely.  As a result of the success of GM and McDonalds, and the influence of Frederick Taylor, the American Business Community has come to worship standards, even in service industry.

I think it's crap.

Studies show that when you take a person and take away their choice - be it in a nursing home or a gulag - the body fails. Key systems simply stop working.  In businesses, productivity plummets.

Yet the typical North-American Cube-Dweller is told when to work (9-to-5), where to work (in what cube), what to work on (by the PMO or his manager), how to build it (by the architect), and what process to use (by the methodology).

Likely he's told what it should look like ('code standards') and when he should be done.

This strips him of his choice.  To those in business, I would like to point out this destroys productivity. To the religious who believe in Social Justice - well, it's a kind of sin.

So, while I will verbally spar with Ron and Steve on philosophy - as peers - I do not believe we should tolerate this kind of rhetoric on this list.  I will oppose it in the strongest terms.

Here is my reply:

The comment I quoted above presupposes corporate-imposed organizational standards are beneficial.  That is not a fact in evidence.  

This is not the Agile you are looking for. Move along.


--heusser
(*) - When you look at Toyota Actually did, not what the first english lean books say, the /workers/ standardized the work, in as far as they saw a need to do so.

[Matthew-103]

Below, I should not have said 'crap.'  I think you can make up your own mind with my inserting such statements.

--heusser

--- In agile-testing@..., "Matthew" <matt.heusser@...> wrote:

>
>
> >But it has the benefit of letting all the teams got familiar
> >with the organization standards, whenever he jumps from a
> >project to another ...
> >
>
> Look. I like a good debate.  To some extent, I value the tussles with Steve Gordon or Ron Jeffries.   While I may disagree with them on a thing or two, I respect that they have actually developed working software - that the methods they talk about, they've, well ... done.
>
> This idea that we need corporate-imposed(*) standards is a different thing entirely.  As a result of the success of GM and McDonalds, and the influence of Frederick Taylor, the American Business Community has come to worship standards, even in service industry.
>
> I think it's crap.
>
> Studies show that when you take a person and take away their choice - be it in a nursing home or a gulag - the body fails. Key systems simply stop working.  In businesses, productivity plummets.
>
> Yet the typical North-American Cube-Dweller is told when to work (9-to-5), where to work (in what cube), what to work on (by the PMO or his manager), how to build it (by the architect), and what process to use (by the methodology).
>
> Likely he's told what it should look like ('code standards') and when he should be done.
>
> This strips him of his choice.  To those in business, I would like to point out this destroys productivity. To the religious who believe in Social Justice - well, it's a kind of sin.
>
> So, while I will verbally spar with Ron and Steve on philosophy - as peers - I do not believe we should tolerate this kind of rhetoric on this list.  I will oppose it in the strongest terms.
>
> Here is my reply:
>
> The comment I quoted above presupposes corporate-imposed organizational standards are beneficial.  That is not a fact in evidence.  
>
> This is not the Agile you are looking for. Move along.
>
>
> --heusser
> (*) - When you look at Toyota Actually did, not what the first english lean books say, the /workers/ standardized the work, in as far as they saw a need to do so.
>

[Steven Gordon-2]

On Wed, Nov 4, 2009 at 6:47 AM, Heba Hosny <heba.hosny@...> wrote:

>
>
>
> On Tue, Nov 3, 2009 at 7:33 PM, Steven Gordon <sgordonphd@...> wrote:
>>
>>
>>
>> On Thu, Oct 29, 2009 at 4:28 PM, wgyouree <wgyouree@...> wrote:
>> >
>> >
>> >
>>
>> well, I was searching for those metrics to help out evaluating our progress, and what are those ways to collect them without imposing reviews on the development team which "that I actually do currently :) "
>

Each development team should be responsible for their process choices.
 They should know what they do and why the choose to do it, and should
iteratively review whether those choices are still best for their
ever-changing project context.

Therefore, it should be no imposition.  In fact, imposing corporate
choices on each team is an imposition.  Management and product
management should, of course, be providing feedback on the results of
the team's work, but not providing any feedback whatsoever on how the
team is choosing to do their work.

>>
>> But it has the benefit of letting all the teams got familiar with the organization standards, whenever he jumps from a project to another, he'll find no change in the steps he should follow, another point: how to evaluate all the projects on common standards as long as each follows his own process?
>> --Heba

This is indeed a tradeoff.  I cannot argue that this might not be a
"benefit", although I do not ever want to work in a context where this
benefit is valued more than the sweeping consequences of achieving
this small benefit.

It is this tradeoff that a company must decide when they choose
between being primarily driven by agile or by CMMI.  To do both is a
cop-out, ignoring that the company must decide what it's core values
are.  If the corporation is primarily agile, CMMI can be 'faked' at a
price if customers demand it.  If the corporation is primarily CMMI,
islands of agile can exist, but it still involves 'faking'.

In either case, the corporate values become 'schizophrenic'.  There
are not only costs to 'faking', but also long term consequences to
schizophrenic corporate values.

SteveG


>
>

[Beaton, Malcolm-2]

So if others on the list disagree they do not deserve respect? Or if you decide that you tire of the discussion they should bow to your opinion?

Unless they are Steve or Ron?

Interesting.

I would have thought that this would be a good place to educate people as to the "Potential" incorrect assumptions they may hold however a zealot is a zealot and whether they are trying to tell me that CMMI OR Agile have all the answers its the "All the answers" bit that I smell the rat in.


"I disapprove with what you say, but I will defend to the death your right to say it."
Evelyn Beatrice Hall

From: agile-testing@... [mailto:agile-testing@...] On Behalf Of Matthew
Sent: 04 November 2009 14:29
To: agile-testing@...
Subject: [agile-testing] Re: Agile or CMMI: Why Not Embrace Both!



>But it has the benefit of letting all the teams got familiar
>with the organization standards, whenever he jumps from a
>project to another ...
>

Look. I like a good debate. To some extent, I value the tussles with Steve Gordon or Ron Jeffries. While I may disagree with them on a thing or two, I respect that they have actually developed working software - that the methods they talk about, they've, well ... done.

This idea that we need corporate-imposed(*) standards is a different thing entirely. As a result of the success of GM and McDonalds, and the influence of Frederick Taylor, the American Business Community has come to worship standards, even in service industry.

I think it's crap.

Studies show that when you take a person and take away their choice - be it in a nursing home or a gulag - the body fails. Key systems simply stop working. In businesses, productivity plummets.

Yet the typical North-American Cube-Dweller is told when to work (9-to-5), where to work (in what cube), what to work on (by the PMO or his manager), how to build it (by the architect), and what process to use (by the methodology).

Likely he's told what it should look like ('code standards') and when he should be done.

This strips him of his choice. To those in business, I would like to point out this destroys productivity. To the religious who believe in Social Justice - well, it's a kind of sin.

So, while I will verbally spar with Ron and Steve on philosophy - as peers - I do not believe we should tolerate this kind of rhetoric on this list. I will oppose it in the strongest terms.

Here is my reply:

The comment I quoted above presupposes corporate-imposed organizational standards are beneficial. That is not a fact in evidence.

This is not the Agile you are looking for. Move along.

--heusser
(*) - When you look at Toyota Actually did, not what the first english lean books say, the /workers/ standardized the work, in as far as they saw a need to do so.

[Matthew-103]

--- In agile-testing@..., "Beaton, Malcolm" <malcolm.beaton@...> wrote:
> So if others on the list disagree they do not deserve respect?
>Or if you decide that you tire of the discussion they should
> bow to your opinion?
>

I was trying to point out the difference between disagreement with strong arguments (Gordon and Jeffries), and marketing-buzzword-speak.

As for my rhetoric, it was over the top, I admit, and I apologize.

If you /have to do/ CMMI, say to win a contract, I would say you can throw in some agile methods to make things better, sure.  But I'd still challenge the premise.

--heusser