Name: Ken Auer

Email address: kauer@rolemodelsoft.com

Organization: RoleModel Software, Inc.

Experience with Agile Methods: Have been working in "informal" agile methods since the mid-1980s and have adopted XP exclusively since 1998 and building our entire "custom software development" business on it.

Check one of the following:

_X_ I want to participate in the eWorkshop at 11:30am EST on 4/8, 2002.

__ I do not wish to participate, but would like to be an observer of the eWorkshop. Send me the URL where I can monitor the meeting, but not contribute.

__ I am unavailable to participate in any form on 4/8, but would be interested in future eWorkshops.

Statement 1: Agile development works better for smaller teams and is more difficult for larger teams, e.g. refactoring can be done only for small systems and great developers.

a. Do you have experiences or data that confirm or refute this statement? (Briefly explain)
We have successfully used XP with many less-than-great developers and have gotten far better results than the less-than-great developers could achieve on their own. Having also been involved with several large projects, it is clearly a fallacy that agile methods can not work for larger teams as long as they are made up of smaller teams and work is coordinated to meet the major goals.
 
b. Can you refine the statement based on your experience (e.g., XP works better for smaller teams but scrum does not, agile works better for teams of size 8 or less, agile works just as well for larger teams as long as the system domain is well understood)?
Coordination of many developers is hard. More planning and coordination is needed for larger teams than smaller teams. There is no inherent reason that this couldn't be done in an agile way. In fact, we would assert that the larger teams should be made up of smaller teams (certainly less than 20, usually less than 10) using agile methods to make sure that each piece is done in a quality way. Less-than-great developers should work closely with great developers to compensate for their lesser skills. This is true no matter how much formal planning is done. It is essential to coordinate all efforts intelligently.
 
c. Can you cite any publications that directly address this statement? (Give citations)
Extreme Programming Applied, Auer & Miller, Addison-Wesley, 2002
"Enterprise Transforming Projects that Don't Kill the Enterprise", Martin Fowler, http://www.martinfowler.com/articles/enterpriseTransformation.html
 
d. What are the implications if this statement is true? How should we change development practices to address this problem?
If the statement were true, nothing would change for "large-scale systems" because they don't embrace agile methods anyway. Hopefully XP and other Agile methods would be more readily accepted as the way to go for small scale problems.

Statement 2: Agile’s emphasis is on designing for current needs, not for future ones. Therefore agile methods work best when the future is unknown, and are less than optimal for projects in which future requirements are known.

a. Do you have experiences or data that confirm or refute this statement? (Briefly explain)
"Future Requirements" are never "known" only hypothesized. They are also difficult to verify because the human mind can find consistencies where there are none. I have been on a plethora of projects where "future critical requirements" were known upfront and, after the passing of years, either became less important, irrelevant, or still in the future. I question the implication that anyone can determine enough about how accurate and unchanging requirements are ahead of time unless they assert that they will not change. Also, I would suggest that agile's emphasis should be re-stated as designing for "currently important needs". I have been on multiple "agile" projects where something that didn't need to be in the product "today" was worked on because showing the capability needed "tomorrow" would generate sales opportunities to forward-thinking customers.
Also, if needs do NOT change, there is no reason NOT to use Agile methods.
 
b. Can you refine the statement based on your experience (e.g., does work well when the future is unknown and requirements churn is high and focus is on delivering on a time, but not when focus is on safety, works just as well for projects with clear future requirements as long as the team has significant experience with agile methods)?
Agile Methods shine bright when requirements are least certain or when change is certain.
 
c. Can you cite any publications that directly address this statement? (Give citations)
Just about all Agile literature addresses the ability for Agile to protect against the dangers of change. On the other hand, it is not clear that any agile method is totally optimal; nor is it clear that any "plan-driven" development approach is optimal. The implication of this statement (based on Dr. Boehm's article) is that "plan-driven" approaches are better when requirments do not change significantly. I certainly concede that plan-driven approaches (given a good plan and a competent team to carry out the plan) can be and have been successful in this situation. However, that does not mean that this approach is better, just more readily accepted.
 
d. What are the implications if this statement is true? How should we change development practices to address this problem?

The implications are that we better have a real good handle on how many changes will occur before we choose our approach. If we could be so accurate in our assessment of the future, it would be clear that we should make such an assessment, and then the choice of "agile" vs. "plan-driven" approach would be obvious. How long does it take to make an accurate assessment? What is the cost of making this assessment relative to the cost of choosing an approach and starting?

Statement 3: Agile methods fit applications that can be built quickly and don’t require extensive quality assurance. Agile methods work less well for critical, reliable, and safe systems.

a. Do you have experiences or data that confirm or refute this statement? (Briefly explain)
I strongly disagree with this statement. I certainly can't speak for all agile methods, but I have seen clearly that XP (with the emphasis of automated acceptance testing and test-first design and coding) produce extremely high quality software. Meeting actual needs accurately, and keeping them working is prevalent in XP from day one. In fact, our experience is that the XP process produces the most reliable software I've ever seen and this has been echoed by our clients. In fact, XP has uncovered sloppiness in requirements early so that the people specifying requirements have to get much more serious than accepting requirements that "look good on paper".
 
b. Can you refine the statement based on your experience (e.g., works well for reliable systems but not for secure/safe ones)?
There is nothing to refine. The statement is false.
 
c. Can you cite any publications that directly address this statement? (Give citations)
Search the XP literature for case studies on people doing "Real XP". Just about everyone points to the improvement in quality and reliability of the software produced over previous experience of both developers and those who specify the requirements.
 
d. What are the implications if this statement is true? How should we change development practices to address this problem?

If this statement were true, it would suggest that Agile Methods are only good for prototypes. This is utter tosh!