Monday, September 30, 2002


Morning Roll Call: Issue 101
"During my days running professional engineering services for a Department of Defense consultancy, we used daily "stand-up" meetings during the (harried) proposal preparation process. Here, the idea was to make the meetings as brief as possible (hence the standup part -- no getting comfortable in a big chair). The meetings were designed to quickly keep everyone informed of progress, to highlight any problems, and to provide cross-team collaboration.

"As you'll see from reading David's article (and references on SCRUM), these types of meetings can have very beneficial effects on a development project."

--Jon Kern

Thursday, September 26, 2002

Agile software development: Review and analysis


Abrahasson, Pekka et al. Agile software development: Review and analysis. ESPOO 2002, VTT Publications 478. 107p.

Keywords: Software development, agile processes, agile methods, extreme programming, agile modelling, open source software development, software project management

Abstract: Agile--denoting "the quality of being agile; readiness for motion, nimbleness, activity, dexterity in motion"--software development methods are attempting to offer an answer to the eager business community asking for lighter weight along with faster and nimbler sofware development processes. This is especially the case with the rapidly growing and volatile Internet software industry as well as for the emerging mobile application environment. The new agile methods have evoked a substantial amount of literature and debates. However, academic research on the subject is still scarce, as most of existing publications are written by practitioners or consultants.

The aim of this publication is to begin filling this gap by systematically reviewing the existing literature on agile sofware development methodologies. This publication has three purposes. First, it proposes a definition and a classification of agile software development approaches. Second, it analyses ten sotware development methods that can be characterized as being "agile" against the defined criteria. Third, it compares these methods and highlights their similarities and differences. Based on this analysis, future research needs are identified and discussed.

Agile User Groups


There are user groups springing up around the Agile Alliance focused on improving development processes along the lines of the Agile Manifesto. I attended the New England Agile User Group on Thursday, 18 September, and a good time was had by all. Ken Schwaber's comments provide a summary of the meeting.

There is also a new user group in Calgary: Calgary Agile Methods User Group (CAMUG)

Sunday, September 15, 2002

SCRUM vs. Waterfall: Point and Counterpoint


Note: CMM is a service mark of the Software Engineering Institute at Carnegie Mellon University.

Shawn Presson, Director of Organizational Practice, ITS Services, Inc. says:

Why, why, why does everything think the waterfall life cycle is exclusively linear? It was designed to be extremely iterative, it allowed for the fact that there may be parallel, non-sequential sets of requirements under development (hence multiple, simultaneous "waterfalls"), it in no way assumed that requirements will be static during a project. It was only after the DoD got its hands on it that this interpretation of the model came about, but why are we listening to the DoD on something like this? ...

Why, why, why do we assume that "repeatable" and "defined" models preclude emergence? These terms are obvious reference to the CMMs, but the CMMs don't lock you into waterfall, spiral, or any other life cycle or methodology. With reference to requirements, the CMM says, "don't let your junior developer bet the farm on meeting a requirement that the project doesn't know about." Does SCRUM cover this point? Great, then SCRUM is the METHOD whereby this important principle (NOT "process") contained in the model is carried out...SCRUM (or JAD, or whatever) is the METHOD whereby your company avoids inadvertently lying about its capabilities (which is what the CMM planning is largely about, anyway.)... (See full text)

Ken Schwaber of the Agile Alliance responds:

Reading Shawn Presson’s comments regarding CMM, waterfall, and agile reminded me of Barry Boehm’s comments at XP/Agile Universe’02 and the comments of several CMM authors at INCOSE’02. I was reminded of the good intentions and sound footings of CMM and Waterfall, both initiated to address problems in systems development and systemic project failures rates that have only marginally improved over the decades...

...CMM, waterfall spring from a different theoretical basis than agile processes. Increased precision and definition are at their core, which is one of the alternatives for controlling a process. However, this approach only works when the definition and the problem have a mapping approaching 1:1 and the problem domain (technical, requirements, and people) is relatively simple: “It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.” Process Dynamics, Modeling, and Control, Ogunnaike and Ray, Oxford University Press, 1992.

The agile process is based on the empirical approach, accepting the complexity of the problem and addressing it through frequent inspection and constant adaptation...Empiricism is seen even in the Agile Manifesto, where the signatories pose agility as an empirical counterpoint to a defined approach, rather than as a new set of defined absolutes. The various agile processes implement empiricism with the underlying practices of iterative development, frequent inspection of status and increments of work, self-organizing teams, emerging architecture and requirements, and solid collaboration... (See full text)