Scrum and XP are widely applied agile methods the two most common, according to at least one survey [Shine03]. However, there is anecdotal evidence indicating some "XP" adoption is misunderstood as simply "not the waterfall" and the teams are merely practicing iterative and evolutionary development or "programming without documentation" and calling this XP.
Scrum's distinctive emphasis among the methods is its strong promotion of self-organizing teams, daily team measurement, and avoidance of following predefined steps. Some key practices include a daily stand-up meeting (the Scrum meeting) with special questions, 30-calendar-day iterations, and a demo to external stakeholders at the end of each iteration.
XP is probably the most well known agile method; it emphasizes collaboration, quick and early software creation, and skillful development practices. It is founded on four values: communication, simplicity, feedback, and courage. It includes 12 core practices, including the whole team working together in a common room, pair programming, constant refactoring, and test-driven development.
The Crystal family of agile methods were developed by Alistair Cockburn [Cockburn02]. While acknowledging the necessity of an iterative lifecycle, in this group of methods Cockburn stresses the primacy of "peopleware" issues over process: communication, education, and so on. His definition of software development shows this emphasis: "…a cooperative game of invention and communication."
Different versions of Crystal (Clear, Yellow, …) contain increasing method weight (or process ceremony in terms of defined and ordered steps, documents, reviews, etc.) as a function of staff size, criticality, and project priority. You choose size and criticality, and this maps to a particular version of Crystal with a recommended method weight. Cockburn has created a scale to illustrate matching method configurations to these factors (Figure 3.2). For example, E6 means a project of 1 6 people, where the worst that can happen from a system failure is loss of essential money. Subsequent chapters refer to this classification model, to classify Scrum, XP, UP, and Evo.
Figure 3.2. Cockburn scale
Agile Modeling is not a complete process or agile method, but a set of principles and practices for modeling and requirements analysis that complement most any IID method [Ambler02]. Scott Ambler summarizes best practices (Figure 3.3) that skilled iterative modelers apply. Briefly, Agile Modeling promotes the collaborative "low-tech, high-touch" creation of barely good enough, disposable models to aid understanding and communication. Practices encourage speed, simplicity, and creative flow.
Figure 3.3. some agile modeling practices
The project room walls are exposed (no furniture against them) and covered in whiteboards and static-cling-sheet whiteboard material. It's Monday, at the start of a three-week iteration. The team of eight developers has decided to spend two or three hours at the walls to better understand and communicate some ideas. Afterwards, they will start programming. They split into groups. Group 1 explores the object design for the main scenario. On one half of one wall, they sketch UML sequence diagrams. It isn't perfect UML; liberties are taken for sketching. After 15 minutes, they move to the other half of the wall, and sketch a class diagram that complements the sequence diagram. Over three hours, they move back and forth, developing two complementary diagrams. Finally, they take pictures, print them, and erase the boards. When programming later, the printouts provide some inspiration some design ideas in code are inspired by the prior thought, and some not.
Other Methods and Practices
In addition to Scrum, XP, and the Crystal methods, there are now a host of other agile-oriented practices or methods in use or publication: