Methods (also called methodologies, although, strictly speaking they are not the same) play a crucial role in software projects. This is particularly so in large projects that include myriad variables such as people, technologies, risks, changing requirements, and fluctuating stakeholders. These variables are far too many to be handled by a single person in the role of a project manager. When the project requires a group of developers to work together, then coordinating and managing their tasks, expectations, and understanding, together with the demands of the customer, becomes highly complex.
Figure 1.2 illustrates the variables of time, budget, functionality, and quality. Balancing these four variables together with the interests of various stakeholders is a complex need that keeps changing from project to project. Methods are an attempt to learn from previous attempts at software development, and then abstract and enshrine these lessons in a discipline. Chapman (2007) describes a software development methodology as a documented set of policies, processes, and procedures employed in the development of an information system. Methods help to abstract, generalize, formalize, unify, and standardize the approaches to software development and maintenance.
Planned methods, in particular, isolate (or at least minimize) the impact of the product quality from the caliber of the individuals. As a result of these, methods equip the management to estimate the time, budget, and resources required in a project at an early stage of the project.
Agile methods, however, are a different brand of methods that subscribe to the Agile Manifesto. Instead of isolating the individual, these Agile methods encourage and respect the subjectivity of an individual and align it in a team effort. Some of these Agile methods have been quite popular and well accepted by the developers. Customers (users), who see the advantages of visible development, are also highly supportive of these approaches. The following is a list of methods belonging to the Agile family:
- Extreme programming (XP) by Beck (2000): Perhaps this is the very first Agile method that is based on simple programming principles and focuses on individuals.
- Scrum (Schwaber, 1995; Schwaber and Beedle, 2001): This is the most popular of all Agile methods; it focuses on business value through demonstration and prioritization. The daily and 2- to 4-week cycles work well in practice.
- Crystal (Cockburn, 2004): This is a family of methods that is applicable to varying development scenarios depending on size and criticality of the projects. However, the range of applicability varies, depending on essential money, discretionary money, and comfort.
- Feature-driven development (FDD) (Palmer and Felsing, 2002): This is based around selection and integration of various development techniques to deliver prioritized features.
- Adaptive software development (Highsmith, 2000): This method continuously adapts/modifies the process to cater to the rapidly changing development situation and is based on the speculate–collaborate–learn phases.
- Dynamic systems development method (Stapleton, 1997): This is an iterative and incremental approach with heavy emphasis on continuous user involvement.
- Test-driven development (Beck, 2002): This method is based on the philosophy of writing the test cases first, before writing the code that is supposed to pass the test cases. It enables focus on quality and purpose of the code. Once the tests are passed, development can include refactoring of the code for future reuse.
A study of these methods and abstraction of their commonalities (described in detail in Chapter 2) forms the basis for the creation of a "composite" approach. Such composite Agile approach can be applied across an organization or to a program of work. This composite Agile approach to projects as well as organizations is envisaged as a very practical means of the use of methods. It forms the basis of most of the discussions in this book.