Agile - Frequently Asked Questions
2. What is the Relationship between Agile and Extreme Programming?
3. What is Special about Extreme Programming?
4. Does an Agile project cost more or less?
5. How do you estimate an Agile project?
6. What if you have developers who can't work in pairs?
7. Can I use Agile on a fixed price project?
8. Can Agile be used for non-IT?
9. How do you control an Agile project?
What are Agile processes?
The goals of Agile processes are the same as the goals of all processes and methodologies, to improve project success by: ensuring business objectives are met, increasing productivity, ensuring high quality, reducing time to market, and reducing risk.
There are three main categories of techniques that can be used to control a project:
1. Pre-definition and pre-planning
2. Handling change and uncertainty
3. People, teams, and communication
Traditional process concentrate on pre-definition - before doing something, work out what you are going to do and write it down. These techniques have many advantages, such as identifying issues up front, enabling external review, and high-level visibility of progress and quality.
Pre-definition is an essential tool for managing many types of projects, such as construction work, where the cost of building is much greater than the cost of modelling, changes are difficult to incorporate later on, low-level tasks are highly predictable and require little creativity, different groups of people with a wide range of specialist skills need to be coordinated, and there is an inherent order to the tasks which have to be carried out.
Historically, software development methodologies are derived directly from large-scale military construction. But software developments projects do not (or need not) have any of the above characteristics. This mismatch is evidenced by the unacceptably high number of software projects which fail.
Agile processes emphasise the other two categories of techniques. Rather than trying to remove change and uncertainty, they accept them as inherent and provide better mechanisms to achieve the required objectives. Rather than trying to make success independent of people, they recognise their importance and seek to utilise their creativity and encourage self-reliance. Even on traditionally-run projects it has been found that these techniques correspond much more closely with project success than adherence to the in-place methodology.
What is the Relationship between Agile and Extreme Programming?
Extreme Programming (XP) is a specific, documented approach to the software development process. "Agile" refers to a family of approaches (see What Are Agile Processes?), of which XP is an example. Other well known examples are:
- Scrum
- DSDM
- Feature Driven Design (FDD)
These approaches are all based on the precept that traditional IT methodologies do not adequately address the main factors contributing to project success, such as team dynamics, communication mechanisms, feedback, handling uncertainty and change. Furthermore, they assert that traditional methodologies add an unnecessary overhead that can contribute directly to project inefficiencies and failure - such methodologies are therefore described as "heavy-weight".
In February 2001 the main exponents of these new approaches met to understand how their individual processes overlapped, and to remove some of the confusion arising for newcomers to the area caused by the range of "competing" approaches on offer. The term "Agile" was agreed on at this time as an umbrella name (although it should be noted that the benefits of these processes are more than just the ability to handle change).
The group became the Agile Alliance, a group of individuals, organisations, and companies who subscribe to and promote the principles embodied in the Agile Manifesto.
What is Special about Extreme Programming?
Agile processes in general are about how to manage the software develop process to make projects more successful. Extreme Programming (XP) is unique in that it incorporates techniques which are specific to the development activity itself.
These techniques address one of the major problems with incremental delivery: working and tested code has to be continually modified. For this reason XP, while usable as a full process in its own right for small projects, has also been integrated with other Agile processes such as Scrum (see www.xbreed.net) and DSDM (www.dsdm.org) for tackling larger projects.
The techniques in question of Refactoring (following predefined small steps for a changing the structure of code without changing its behaviour) and Test Driven Design (code is written in response to have first written a test which fails).
XP (Extreme Programming) is only one example of a family of new approaches to software development which are collectively termed "agile". However, XP has received the lion's share of the headlines, generated the fiercest debate, and has the largest adoption profile. Furthermore, XP is now being used alongside other Agile approaches, rather than in competition (see scrum and XP, Dsdm and XP).
What makes XP stand out from the crowd is that it incorporates a technique which could be as profound for the way that code is written as the introduction of object-oriented techniques was in the 1980s. The technique in question is Refactoring, which is incorporated into the more fully developed technique of Test-Driven Design.
Does an Agile project cost more or less?
An Agile project should cost less.
Some Agile practices will clearly add to the cost. Pair programming in Extreme Programming is an obvious example. Incremental delivery can also add to the cost, through changing existing code, additional testing, and supporting early releases.
These costs should be more than offset by savings elsewhere. It is inherent in a 'light-weight' process that overheads are reduced, such as producing detailed up-front documentation, and its subsequent maintenance. Management overhead in particular should be significantly reduced. Any investment in quality, such as pair programming, regression testing, keeping the design consistently high (refactoring), continuous integration, and eliciting user feedback, should all provide returns in the later stages of the project.
However, the major cost savings are derived by simply implementing less functionality. An analysis of any application which is specified up-front will identify a percentage of functionality which is never or seldom used. Indeed, it can be argued that there is a need when defining requirements to build in a safety margin - to leave out a function that might be important would be unprofessional.
In our experience, as a conservative estimate, non-essential functionality can account for upwards of 30% of an applications cost, taking into account its impact on such things as complexity, performance, and usability.
How do you estimate an Agile project?
Estimating an Agile project is similar to producing a budgetary estimate for any project. A short scoping exercise is used to produce a high-level costing which is refined over time.
Agile techniques differ in that:
- More emphasis is placed on the impact of team issues
- Higher levels of communication and feedback are incorporated during the estimation process (for example, holding planning workshops, including on-the-fly estimation to help guide thinking)
- The principles of prioritisation would be adopted to keep focus on the key issues
- Detailed task and dependency planning are not considered useful, as task definition, assignment, and interaction are much more fluid
- Any decisions made to support the estimation process would not be imposed upon the resultant work
Generally, Agile projects would not propose doing any more detailed top-down estimation. The degree of uncertainty across the whole set of project parameters is difficult to predict and cannot be fully eradicated by prior analysis.
Agile processes accept the inherent uncertainty of estimates. They propose that effort and process is better spent making sure the error does not cause project failure (through prioritisation and feedback) rather than trying to increase the accuracy.
What if you have developers who can't work in pairs?
Pair programming is just one technique used within Agile methods. Whilst it is a powerful tool for increasing communication, gaining focus on issues, problem solving and increasing quality, if people refuse to work using it, it does not stop other Agile techniques being applied to a project.
When first asked to work in pairs, many people initially find it difficult but after two to three weeks discover it is one of their most liberating work experiences. A key part of introducing pairing is to ensure that experienced individuals are on hand to provide coaching and guidance. If an individual still finds it impossible to work in pairs, it may well be indicative of communication or relationship issues that need to be resolved, regardless of whether pairing is being used or not.
Can I use Agile on a fixed price project?
Yes. Fixed price projects typically involve developing a system to a fixed budget against a detailed scope with the developer holding the contingency and assuming the majority of the development risk. As such, this disables the ability to invoke one of Agile's most powerful benefits - flexibility of scope.
The techniques that can bring about the largest benefits for a project involve developing the simplest system possible to meet the users' requirements. As these requirements evolve over the life of the project, Agile techniques allow a development to capture and embrace this change as it happens. By trying to capture every requirement at the start of the project and then minimise change throughout a development lifecycle, fixed price projects work against this agility.
However, many other Agile techniques can still bring benefit within a traditional fixed price approach. Techniques such as pairing, test driven design and others encourage communication between team members and greatly increase quality, ultimately reducing the overall lifetime costs for a system.
If a new project is being considered there are other commercial models that work to an agreed budget, but without the constraints of a full fixed price environment.
Can Agile be used for non-IT?
Many Agile techniques are applicable to non-IT projects. Many of the techniques and principles were pioneered in projects outside the It industry. There are two main categories of Agile techniques (see What Are Agile Processes?):
1. Handling change and uncertainty
2. People, teams, and communication
Techniques for handling change and uncertainty can be applicable wherever project objectives are likely to change (external market forces, new business processes, competition) but the timescales need to be minimised, or where there is inherent uncertainty (complex goals, use of new technology, research and development projects).
Techniques for organising teams better are applicable where wherever the tasks people are performing are highly creative, and the decisions made by individual teams can affect the entire project requiring high degrees of collaboration.
How do you control an Agile project?
Agile projects use small iteration cycles to provide early and frequent feedback on real progress.
The feedback concentrates on what is completed, to a releasable standard. This makes the quality of information much higher than on traditional projects where the criteria for 'completion' of an interim task are more subjective - when is a specification complete?
The tasks carried out within each iteration of an Agile project are broadly constant. Information gathered for any one iteration can therefore be used to effectively improve subsequent iterations. The manager has the choice of level at which to monitor and intervene in the project. At the end of each iteration if progress is less than anticipated then he may choose to monitor closely within an iteration, although this is not usually required.
The short iteration cycles mean that problems cannot remain 'hidden' for long periods of time. If more immediate information is required management can easily 'dip' into the development cycle within an iteration. Daily Scrum meetings and feedback from pair programming provide clear indications as to the current state of an iteration. Additionally experience suggests that teams with collective responsibility, as engendered through Agile, are more likely to communicate issues upwards.