Suitability of Agile Methods
Or agile methods are generally suitable depends on the chosen viewpoint. From a product perspective, agile methods as appropriate requirements are vague and changeable, they are less suitable for systems that must meet the critical requirements such as reliability and security, although there is no complete consensus about this. From an organizational perspective, the capability will be measured by three dimensions: culture, people and communication. In this context, a number of success factors indicated:
The culture of the organization should be open to discussion and negotiation
People must be trusted
Fewer but more competent people
Organizations must accept the decisions that developers take
Organizations must have an environment where rapid communication between team members is possible
The most important factor may be the project scope. Personal communication within a project team becomes more difficult as the size increases. Why agile methods suitable for small projects not exceeding 20 to 40 people.
Another problem is that assumptions at the start or an excessively rapid gathering of requirements before a deviation from the optimal solution can cause, especially if the customer has not expressed its wishes. Likewise, it is, given human nature, may well be a “dominant” one developer serious personal stamp on the design that does not have to correspond with the desired project outcome. Historically, developers can impose their solutions to customers, they convince the best and ultimately find that the solution does not work. In theory, this should reduce speed iterative nature, but it is assumed that when there is negative feedback. If there is no question of the derogation can increase rapidly.
This objection could be eliminated by the requirements to establish a separate phase (common in agile systems) and so to isolate the influence that developers have to exercise, or by continually developing customer involvement and any intermediate step to get tested. Problem is that customers will not have much time investing in them. It also complicates the QA (Quality Assurance) because no clear (SMART) test objectives that do not change from release to release.
Using DSDM as a ‘Suitability Filter
The suitability of individual agile methods to provide a deeper analysis is necessary. The DSDM method is therefore provided an example ‘suitability filter’. The Crystal family of methods provides a method by which criteria can be selected for a certain project. While the selection is based on project size, interest and priorities. Other agile methods do not provide such explicit tools to determine their suitability.
Certain methods such as DSDM and Feature Driven Development (FDD), is said to be suitable for all development, regardless of environmental factors (Abrahamsonn et al, 2003). at least in software.
A comparison of agile methods will reveal that they each have their own stage of a software development life cycle support. These individual characteristics of agile methods can obviously well used for their selection for a specific project.
Agile development has been extensively documented (see Agile development in the profession, below, as well as Beck, pg. 157, and Boehm and Turner pg. 55-57) to work well in small (<10 developers) co-located teams .
The question is not answered or agile development is suitable for the following scenarios:
Large-scale developments (> 20 developers), but there are proposals
Distributed development (non-co-located teams around the globe as well). Proposals have been made in Bridging the Distance and Using an Agile Software Process with Offshore Development
Projects of strategic and vital Hierarchical organizations.
Agile Development Successes
Interestingly, several major successes have been recorded at organizations such as BT Group, which possessed hundreds of developers located in the United Kingdom, Ireland and India, who worked together on projects in agile methodologies. Although undoubtedly be questioned about the suitability of agile methods for certain project types, size or geographical spread are apparently no insurmountable barriers to success.
Barry Boehm and Richard Turner suggest that risk analysis should apply to choose between adaptive (“agile”) and prescribing methods. According to them, both ends of the continuum, their very survival.
Agile Development rationale:
Large solution space
Senior Developer
Highly variable project requirements
Small number of developers
Culture that thrives in chaos
Basis for prescribing methods exist:
Cutting Specifications
Junior Developer
Predetermined project requirements
Many developers
Culture that order requires
Agile methods and customized method
Different terms are used to adapt method (‘method adaptation’) to denote such as “method tailoring ‘,’ method fragment adaptation ‘and’ situational method engineering. Customized method (“method tailoring) is defined as:
a process or skill which human factors medicine for developing a system for a specific project situation determined by concerted changes, and the dynamic interaction between contexts, intentions, and fragments of methods.
Almost all agile methods are potentially eligible for customization. Even the DSDM method is used for this purpose and has successfully tailored in a CMM context. As a feature that can distinguish between agile methods and traditional development methods, the latter being inflexible and prescriptive, situational adjustment is considered. Practical consequence is that agile methods project teams enables practices to suit individual project needs. Practices are concrete activities and products that are part of a methodical framework. At an extreme level, the philosophy behind the method, consisting of a number of””’principles’ to adapt (Aydin, 2004).
In the case of XP is the need for method adaptation explicit. One of the fundamental assumptions of XP is that no process exists that is applicable to each project, but that practice to the individual project needs to be adjusted. There are no experience reports in which XP practices are included. On the other hand several occasions report partial implementation of XP practices is done.
It can distinguish between static and dynamic method adaptation. The basic assumption behind static method adaptation is that the project context is given at the start and remains throughout the project. Resulting in a static definition of the project context. With such a definition, a choice can be made from fragments of structured methods. In contrast to dynamic method adaptation is assumed that the project context in development. This means that the project is highly unpredictable and subject to change. Advance can not be determined which fragments of methods will be applied. Project managers will therefore, during the execution of projects, to have to switch to method-fragments themselves their need to adapt or even invent new. (Aydin et al, 2005).
Agile Methods and Project Management
Agile methods differ substantially in how they project management overlap. Some methods are supplemented with guidelines for project management.
Measuring Agility
Although agility (agility) is seen as a means to an end, there are several proposals in order to quantify. Agility Index Measurements (AIM) measurement projects with a number of agility factors. The near-namesake Agility Measurement Index, set against developments five dimensions of a project (time, risk, novelty, effort, interaction). Other techniques are based on measurable goals. In a study that uses fuzzy mathematics proposes that project velocity as a measure of agility.
The practical applicability of these measures remains to be seen.
Overview of Agile methods
Some well known agile-development methods:
Extreme Programming (XP)
Scrum
Agile Modeling
Adaptive Software Development (ASD)
Crystal Clear and Other Crystal Methodologies
Dynamic Systems Development Method (DSDM)
Feature Driven Development (FDD)
Lean Software Development
Agile Unified Process (AUP)
Continuous integration
Other approaches:
Agile Documentation
Iconix Process
Microsoft Solutions Framework (MSF)
Agile Data Method
Database refactoring
When you need to learn more about the agile model for school or your project, I strongly recommend anyone to get this book: The Agile Samurai by Pragmatic Programmers. It’s only $22.83 and tought me way more then any other book (and I’ve read a lot on the subject!).