I was quite stunned (to say the least) when I read an article published in Communication of the ACM (October 2006 issue). The article has some fundamental misunderstandings about Agile Software Development and Methodologies in general. Here are some of the excerpts that caught my attention and then my comments on them:Here's a few examples:"(...) agile development relies on ongoing negotiations between the developer and the customer for determining the acceptable levels of quality at various stages of development. How can we achieve a balance between fixed and evolving quality requirements?"In this paragraph alone (page 42) there are several misconceptions: First, many Agile methodologies (XP for example) have very strict focus on qualitySecond, Lean (which is an inspiration for some agile methods, like scrum) defend quality is a non-negotiableThird, quality is very much linked to the concept of DONE in scrum. In Scrum the team defines what DONE means, not the customer... Of course they talk to the customer, but quality is non-negotiable because we know that bad quality (even if the customer wants that) will lead to very slow pace of development.This paragraph is a clear statement to the lack of understanding that the authors of the article have over Agile Software Development and the underlying (experimental) background."Agile environments, on the other hand, are more people-oriented and control is established through informal processes. What would be the appropriate balance between people- and process¬-oriented control in agile distributed environment?"In this paragraph (page 42) they mix the communication barriers problem (which is typical in distributed environments) with the level of ceremony (to use a Cockburn term) for a certain process. This is another basic mistake in non-Agile experts. Agile development processes are "empirical" but "strict", they are not "informal" even if an experienced team will have the "strict" process as tacit knowledge, in which case the process will _appear_ informal."The practices that may be characterized as agile but disciplined have evolved in the three organization after repeated experimentation" Experimentation is at the core of Agile. So using this conclusion (which they don't back-up with evidence - just state) we could assume that the process the organizations are using is indeed an Inspect & Adapt type process which would fit in the Agile set of values. However, they also use the phrase "agile but disciplined" to describe the practices, which in turn shows that the authors do not understand Agile at all. Look at XP, XP is an Agile methodology with a high level of discipline. There's no contradiction between Agile and discipline... Basic stuff but the authors don't get it."Skeptical of agile development that does not include adequate upfront design, both Manco and Consult devoted the first two or three iteration of a project to finalize critical requirements and develop a high-level architecture."(page 42) Having iterations for Design only is not Agile. FDD (another Agile method) does advocate that you do some upfront design, but it also states that you should go to coding quite soon after that and refine the design as you go. The biggest problem with this paragraph is that they don't define "adequate upfront design" — this is a basic mistake and should never have been published..."At Telco, the offshore team felt that such minimally documented requirements were more helpful than just informal communication." Again in this paragraph (page 43) they confuse communication with methodological philosophy. Documentation (as described in the article) is needed due to distribution, not per se. The Agile manifesto states that documents are also needed, but you should put your effort in making communication work (face-to-face if possible) rather than having _everything_ carefully documented before coding. Another basic confusion and misconception patent in the paragraph."Short-cycle but not time-boxed development" (page 43) Time-box is not a requirement of Agile, but recent knowledge does advocate quite strongly that time-boxes are the right way to tackle software development. On the other hand, if the teams were not time-boxing, that means they were scope-boxing. I'd suggesting going with FDD for those cases when the scope if fixed (BTW: FDD also uses time-boxes, but those are used to establish a rhythm for the development, not for defining the final scope)."Project leads and champions at Consult were on call almost round-the-clock via their Blackberries"This phrase (page 44) suggests that even though some people in the project may have been using some Agile methods (or more likely practices) they were not following something that is a key agile principal (number 8): Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.If we take the stand that the principles must be followed for the project to be considered Agile, then the conclusion in the article is just plain wrong. Note that it is possible to use some XP practices even in a waterfall project..."The practices presented here demonstrate how a balance between agile and distributed approaches can help meet these challenges."(page 46) Balance between agile and distributed? Jeff Sutherland has an article where he describes an Agile project (fully, not "balanced") can happen in a distributed environment. It is foolish to "balance" distributed and Agile, you cannot "do" agile, you have to "be" agile. If you are not following the principles and values (practices are not mandatory) then you "are not" agile. This last phrase in the conclusion section of the article further reflects the lack of understanding of the authors of this article.Jeff Sutherland's article on distributed agile: "Distributed Scrum: Agile Project Management with Outsourced Development Teams", Sutherland et al., Proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS'07) Posted by

I was quite stunned (to say the least) when I read an article published in Communication of the ACM (October 2006 issue). The article has some fundamental misunderstandings about Agile Software Development and Methodologies in general. Here are some of the excerpts that caught my attention and then my comments on them:

Here's a few examples:

"(...) agile development relies on ongoing negotiations between the developer and the customer for determining the acceptable levels of quality at various stages of development. How can we achieve a balance between fixed and evolving quality requirements?"

• In this paragraph alone (page 42) there are several misconceptions:
• First, many Agile methodologies (XP for example) have very strict focus on quality
• Second, Lean (which is an inspiration for some agile methods, like scrum) defend quality is a non-negotiable
• Third, quality is very much linked to the concept of DONE in scrum. In Scrum the team defines what DONE means, not the customer... Of course they talk to the customer, but quality is non-negotiable because we know that bad quality (even if the customer wants that) will lead to very slow pace of development.
• This paragraph is a clear statement to the lack of understanding that the authors of the article have over Agile Software Development and the underlying (experimental) background.

"Agile environments, on the other hand, are more people-oriented and control is established through informal processes. What would be the appropriate balance between people- and process¬-oriented control in agile distributed environment?"

• In this paragraph (page 42) they mix the communication barriers problem (which is typical in distributed environments) with the level of ceremony (to use a Cockburn term) for a certain process. This is another basic mistake in non-Agile experts. Agile development processes are "empirical" but "strict", they are not "informal" even if an experienced team will have the "strict" process as tacit knowledge, in which case the process will _appear_ informal.

"The practices that may be characterized as agile but disciplined have evolved in the three organization after repeated experimentation"

• Experimentation is at the core of Agile. So using this conclusion (which they don't back-up with evidence - just state) we could assume that the process the organizations are using is indeed an Inspect & Adapt type process which would fit in the Agile set of values. However, they also use the phrase "agile but disciplined" to describe the practices, which in turn shows that the authors do not understand Agile at all. Look at XP, XP is an Agile methodology with a high level of discipline. There's no contradiction between Agile and discipline... Basic stuff but the authors don't get it.

"Skeptical of agile development that does not include adequate upfront design, both Manco and Consult devoted the first two or three iteration of a project to finalize critical requirements and develop a high-level architecture."

• (page 42) Having iterations for Design only is not Agile. FDD (another Agile method) does advocate that you do some upfront design, but it also states that you should go to coding quite soon after that and refine the design as you go. The biggest problem with this paragraph is that they don't define "adequate upfront design" — this is a basic mistake and should never have been published...

"At Telco, the offshore team felt that such minimally documented requirements were more helpful than just informal communication."

• Again in this paragraph (page 43) they confuse communication with methodological philosophy. Documentation (as described in the article) is needed due to distribution, not per se. The Agile manifesto states that documents are also needed, but you should put your effort in making communication work (face-to-face if possible) rather than having _everything_ carefully documented before coding. Another basic confusion and misconception patent in the paragraph.

"Short-cycle but not time-boxed development"

• (page 43) Time-box is not a requirement of Agile, but recent knowledge does advocate quite strongly that time-boxes are the right way to tackle software development. On the other hand, if the teams were not time-boxing, that means they were scope-boxing. I'd suggesting going with FDD for those cases when the scope if fixed (BTW: FDD also uses time-boxes, but those are used to establish a rhythm for the development, not for defining the final scope).

"Project leads and champions at Consult were on call almost round-the-clock via their Blackberries"

• This phrase (page 44) suggests that even though some people in the project may have been using some Agile methods (or more likely practices) they were not following something that is a key agile principal (number 8): Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• If we take the stand that the principles must be followed for the project to be considered Agile, then the conclusion in the article is just plain wrong. Note that it is possible to use some XP practices even in a waterfall project...

"The practices presented here demonstrate how a balance between agile and distributed approaches can help meet these challenges."

• (page 46) Balance between agile and distributed? Jeff Sutherland has an article where he describes an Agile project (fully, not "balanced") can happen in a distributed environment. It is foolish to "balance" distributed and Agile, you cannot "do" agile, you have to "be" agile. If you are not following the principles and values (practices are not mandatory) then you "are not" agile. This last phrase in the conclusion section of the article further reflects the lack of understanding of the authors of this article.
• Jeff Sutherland's article on distributed agile: "Distributed Scrum: Agile Project Management with Outsourced Development Teams", Sutherland et al., Proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS'07)