The basic idea of agile development process is that the development team can be more effective in responding to changes if it can

To reduce the cost of moving information between people, the agile team works to

To reduce the time from decision to feedback, the agile team,

The term agile, coined by a group of people experienced in developing software this way has two distinct connotations. The first is the idea that the business and technology worlds have become turbulent, high speed and uncertain, requiring a process to both create change and respond rapidly to change.

The second one suggests that an agile process requires responsive people and organizations. Agile development process focuses on the talents and skills of the individuals and molds process to specific people or teams, not the other way around.

Agile process is sometimes defined as useful light-but-sufficient rule of project behaviors and the use of human and communication oriented rules. The agile process is both light and sufficient. The figure below describes Extreme Programming methodology which is based on agile development process.

 

The lifecycle of XP consists of five phases

1. Exploration phase

2. Planning phase

3. Iteration to Release

4. Productionizing phase

5. Maintenance phase

6. Death phase

 

In the exploration phase, the customers write out the story cards that they wish to be included in the first release. Each story card describes a feature to be added into the program. At the same time the project team familiarize themselves with the tools, technology and practices they will be using in the project. The technology to be used will be tested and the architecture possibilities for the system are explored by building a prototype of the system. The exploration phase takes between a few weeks to a few months, depending largely on how familiar the technology is to the programmers.

 

The Planning Phase sets the priority order for the stories and an agreement of the contents of the first small release is made. The Programmers first estimate how much efforts each story requires and the schedule is then agreed upon. The time span of the schedule of the first release does not normally exceed two months. The planning phase itself takes a couple of days.  

 

The Iteration to release phase includes several iteration of the systems before the first release. The schedule set in the planning stage is broken down to a number of iterations that will each take one to four weeks to implement. The first iteration creates a system with the architecture of the whole system. This is achieved by selecting the stories that will enforce building the structure for the whole system. The customer decides the stories to be selected for each iteration. The functional tests created by the customer are run at the end of every iteration. At the end of the last iteration the system is ready for production.

 

The Productionizing phase requires extra testing and checking of the performance of the system before the system can be released to the customer. At this phase, new changes may still be found and the decision has to be made if they are included in the current release. During this phase, the iterations may need to be quickened from three weeks to one week. The postponed ideas and suggestions are documented for later implementation during, e.g., the maintenance phase.

 

After the first release is productionized for customer user, the XP project must both keep the system in the production running while also producing new iterations. In order to do this, the Maintenance phase requires an effort also for customer tasks. Thus, the development velocity may decelerate after the system is in production. The maintenance phase may require incorporating new people into the team and changing the team structure.

 

The Death phase is near when the customer does no longer have any stories to be implemented. This requires the system satisfies customer needs also in other respects (concerning performance and reliability). This is the time in the XP process when the necessary documentation of the system is finally may also occur if the system is not delivering the desired outcomes, or if it becomes too expensive for further development.