Essential Ideas About Agile Methods by Scott Duncan:  My involvement with standards, methodology and process issues brings me in contact with people who ask what agile methods are or what they are about.  Many have not heard of the Agile Manifesto and associated principles.  When I ask what they have heard about agile methods, I am told things like pair programming, no documentation, refactoring, iterative development, no planning, daily “stand-up” meetings, etc.  Of course, none of these get at the heart of what agile methods are “about” (beyond the fact that some are not true).

Based on listening to the creators of agile methods and reading what they have written on the subject, agile methods, above all else, seem to me to be about expanding the bandwidth and frequency of communication and about being open to change.  Essential to both of these is the existence of effective feedback, which is required for meaningful communication and productive change. The values, principles and practices of agile methods seem to flow from seeking to achieve these objectives.

Author: Scott Duncan        Date Original Version Posted: February, 2007

Author: Linda Westfall        Date Original Version Posted: February 28, 2006

A Methods "Discussion/Debate: Method Agility or What's a Methodology For? What’s the “right” method to use for a software development project according to all the “best practices” advice?  How would you answer this question or is this really a sensible question to ask?  Many folks advocating “lite” or agile methods would suggest there is no “best” practice you can apply across the board.  Articles and columns in IEEE and ACM publications have addressed this very point.  On the other hand, advocates of “disciplined” methods (to use the term Boehm and Turner have in their book on agile and more formal methods) would say there is vast industry experience pointing to “best practices.”  This paper, from Scott Duncan's presentation/discussion session at the 14th International Conference on Software Quality, is about beginning the process of answering some methodology related questions.

Author: Scott Duncan        Date Original Version Posted: September 5, 2005

The What, Why, Who, When and How of Software Requirements: If the software requirements aren’t right, you won’t end up with the software that you need.  The original version of this paper was presented by Linda Westfall at the World Conference on Quality and Improvement 2005.  The updated version was published in the ASQ's Software Quality Professional Journal.  This article discusses:

  Why: the benefits of having the right software requirements

  What: the various levels and types of requirements that need to be defined

  Who: identifying the stakeholders of the software requirements and getting them involved in the process

  When: requirements activities throughout the software development lifecycle

  How: techniques for eliciting, analyzing, specifying and validating software requirements

Author: Linda Westfall        Date Original Version Posted: May 7, 2005

Recommended References

Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley, Boston, 2001.

Capability Maturity Model Integration (CMMI) for Development, Version 1.2, Carnegie Mellon University Software Engineering Institute, Pittsburgh, PA 15213-3890, CMU/SEI-2006-TR-008, ESC-TR-2006-008, (available on the SEI website).

Donald Gause and Gerald Weinberg, Exploring Requirements, Quality Before Design, Dorset House Publishing, New York, NY, 1989.

Robin F. Goldsmith, Discovering Real Business Requirements for Software Project Success, Artech House, Boston, 2004.

Ellen Gottesdiener, Requirements by Collaboration, Addison-Wesley, Boston, 2002.

Karl E. Wiegers, Software Requirements, 2^nd Edition, Microsoft Press, Redmond, WA, 2003.

Ralph Young, The Requirements Engineering Handbook, Artech House, Boston, 2004.

Recommended Links