Overview

Synopsis

In "Agile Software Development", Alistair Cockburn compares software development to a cooperative, goal-seeking, finite group game of invention and communication, where the primary goal is to deliver working software, and the secondary goal is to set up other work products for the next game (e.g., maintenance). Cockburn covers the concepts and principles behind agile methodologies necessary for software developers, project managers, and sponsors to achieve repeatable success in their projects.

Table of Contents

Introduction: Unknowable and Incommunicable
Chapter 1. A Cooperative Game of Invention and Communication
Chapter 2. Individuals
Chapter 3. Communication, Cooperating Teams
Chapter 4. Methodologies
Chapter 5. Agile and Self-Adapting
Chapter 6. The Crystal Methodologies
Appendix A. The Agile Software Development Manifesto
Appendix B. Naur, Ehn, Musashi
Appendix C. Books and References

Praises

I was pleasantly surprised by the digest of software development principles leading up to the discussion agile methodologies in chapter 5. These issues are present even in traditional (non-agile) methodologies and worth reading, particularly these sections from chapters 2 and 3:

Them's Funky People.
Overcoming Failure Modes.
Working Better in Some Ways than Others.
Drawing on Success Modes.
Convection Currents of Information.
Jumping Communications Gaps.
Teams as Communities.
Teams as Ecosystems.

Other interesting discussions include the three levels of learning and mastering new skills (Cockburn, 14-18), and programming as theory building (Cockburn, 227-240).

Criticisms

I would have liked to have seen a description of the other agile methodologies (or interests) represented by the respective manifesto founders (i.e., beyond XP in chapter 4 and the Crystal methodologies in chapter 6). This could then be supplemented by a capability comparison of various methodologies using the criticality vs. people grid. (Cockburn, 162)

I don't fully agree with the qualifiers used to characterize a "methodologically successful" project. (Cockburn, 145) First, a project using a previously "successful methodology" is not guaranteed to succeed. Second, a project using a previouly "successful methodology" doesn't necessarily fail if the leadership changes (for reasons other than dismissal) or if people do some things differently.

Final Analysis

Building on a lengthy discussion of software development principles and methodology concepts, Cockburn provides the means to select, evaluate, and design (or more likely, alter) agile methodologies. This ability will become increasingly important as organizations strive to increase customer satisfaction, lower costs, and improve software quality.

Copyright

Copyright © 2003 Anthon Pang.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".