I have always found Alistair Cockburn's Crystal family of agile methodologies to be among the most pragmatic approaches to software development. [1] Cockburn advocates that teams should adopt a specific instance of a methodology based on risk and scale factors for their projects. In the second edition to his book, Agile Software Development (with new subtitle "The Cooperative Game"), Cockburn updates his ideas on software development, with particular emphasis on "the cooperative game of invention and communication."
The first three chapters of the book discuss theories for treating software development as a cooperative game of delivering software and then setting up for the following game; considering "funky" people and the ways that they contribute to project success; and the costs and benefits associated with team communication. Cockburn's anecdotes clearly bring home his recommendations that organizations need to improve the flow of information and the cultural barriers among teams and their members.
In chapter four, Cockburn presents
Advertisement
seven principles that he feels are important to designing and evaluating methodologies, and the resulting consequences:
Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information.
Excess methodology weight is costly.
Larger teams need heavier methodologies.
Greater ceremony is appropriate for projects with greater criticality.
Increasing feedback and communication reduces the need for intermediate deliverables.
Discipline, skills, and understanding counter process, formality, and documentation.
Efficiency is expendable in non-bottleneck activities.
One of the most interesting concepts in the book (chapter 5) is the discussion about "becoming self-adapting." This lies at the core of a successful agile project: the ability to recognize and reflect upon what your team is doing and adapt to improve success for future (and likely different) projects. Cockburn provides a framework for teams to determine how agile they are, to introduce agile processes into an organization, and to use agile approaches outside software development, such as for project portfolio management, customer relations, and contracts.
Cockburn concludes the book by demonstrating how his family of Crystal Methodologies address these needs of communication, people-centric project teams, and the need for multiple approaches to different project requirements. By using examples from projects that have implemented Crystal Clear, Crystal Orange, and Crystal Orange Web methodologies, Cockburn shares how projects have addressed challenges of business-criticality, large team sizes, and lack of experienced staff.
No single process will satisfy the needs of an organization's project portfolio. Individual project teams will always need to tailor a process to fit specific project criteria. That said, teams within a development organization must try to achieve some level of consistency of terminology, metrics, and approaches across projects, if they are to remain productive resources to the company. Regardless of the specific Agile process that you choose, Cockburn's Crystal framework presents a useful model from which to tailor your process, while maintaining some consistency across all projects.
Home 
