As we've stated before, Agile/XP is a light-weight methodology that allows teams to develop software in the face of vague and rapidly changing requirements. This light-weight methodology combines a set of principles, practices and processes that allows the development team to build software quickly and build software properly. The methodology can be successfully deployed in small, medium or large-scale business environments.

At the heart of the methodology is the Product Team. This team contains all of the skills necessary for successfully delivering a working software product. It includes people who perform the roles of a product owner, developer, architect, quality assurance, requirements engineer, business analyst, documentation specialist, and user interface designer. It also includes a person who is an actual customer of the product or who can act on the customer's behalf. This person plays a pivotal role in defining concrete requirements, prioritizing requirements and setting acceptance criteria for requirements. By working together, this team moves from initial concept to final delivery.

Agile/XP Principles

Behind Agile/XP is a set of principles. In the Agile/XP world, high value is placed on communication, simplicity, feedback and spirit. These values are expressed as principles in the Agile Manifesto For Software Development. The manifesto was developed by some of the software industry's most renowned thought leaders. You can read the manifesto yourself, but the principles have been summarized below:

early and continuous delivery of valuable software
frequent delivery of working software
working software is the primary measure of progress
welcome and adapt to changing requirements
demand daily communication between business people and development
demand direct communication between business and development
build projects around teams of motivated people
trust and support the teams
allow teams to work at a pace that can be sustained forever
allow teams to organize themselves
allow teams to reflect on their successes and failures
strive for simplicity in design and execution
strive for technical excellence in design and execution

These principles form the foundation for the rest of the Agile/XP methodology.

The Process

Agile/XP teams use an iterative design process. The process is described briefly below:

Envisioning
The process begins with envisioning where the team gathers information about the market and the product. They assess the risks associated with building the product from a market and development perspective. Product requirements are entered into a requirements backlog and risks are entered into a risk backlog.
Definition
The team proceeds to definition where product requirements are converted into product features containing concrete use cases and acceptance criteria. These features are sorted into product releases and initial development estimates are created. In addition, a product architecture is also created. In large-scale development environments, teams are organized around the architecture (e.g. application teams, component teams, platform teams) and given ownership for specific parts of the architecture.
Development
From there, the team proceeds into the development. The teams divided the features they need to develop into stories. These stories are small units of functionality taking about a week or two to code and test. Developers now prepare estimates for the stories and compare their estimates to the original estimates created during the definition phase. Discrepancies or anomalies between the estimates are resolved through negotiation. This process ensures the integrity of the estimates. It allows the customer to prioritize development based on the value and time cost of the stories. It allows developers to "own" and "commit" to their deliverables. And it allows "stakeholders" to set release dates that can be used by the rest of the company. Development is done iteratively and incrementally using Test Driven Development Model and a Continuous Build and Integration Environment. Test are written for each unit of code and only code that passes its test is committed to the build. Every two weeks, the development team delivers working stories that pass their tests.
Release Engineering
End-to-end release engineering is performed on an ongoing basis as the development proceeds and the product evolves. Like unit tests, end-to-end acceptance tests are run from day one to ensure the overall continuity and integrity of the system as a whole. As a result, a robust and reliable system grows in functionality, piece by piece, from the very first day. This means that, at any point in time, a "potentially shippable product" is available for release. Practically speaking, it is highly unlikely that the initial builds would actually be "shipped" but the theory behind the Agile/XP methodology is that any software developed should be reliable and robust at any point in time.

Throughout this iterative process, progress is measured and tracked by automatically querying the code library and generating daily and weekly reports. Everyone from developers to stakeholders can see how many stories have been built, how many stories have passed their tests, how many stories have failed and how many stories still need to be built. So rather than relying on "hand-crafted" GANT charts, Excel spreadsheets or PowerPoint slides, Agile/XP measures progress by interrogating the system itself. In essence, the system becomes the measure of its own success.

The Practices

Making the Agile process work requires a collection of best practices. Here is a list of some of the practices (in alphabetical order) that are used to turn Agile into a reality.

Acceptance Testing
The customer writes acceptance tests. The tests demonstrate that the story is complete. The programmers and the customer automate acceptance tests. Programmers run the tests multiple times per day.
Coding Standards
The code needs to have a common style to facilitate communication between programmers. The team owns the code; the team owns the coding style.
Collective Ownership
The team owns the code. Programmer pairs modify any piece of code they need to. Extensive unit tests help protect the team from coding mistakes.
Continuous Integration
Programmers integrate and test the software many times a day. Big code branches and merges are avoided.
Customer Team Member
Teams have someone (or a group of people) representing the interests of the customer. They decide what is in the product and what is not in the product.
Metaphor or Vision
The system metaphor provides an idea or a model for the system. It provides a context for naming things in the software, making the software communicate to the programmers.
Open Workspace
To facilitate communications the team works in an open workspace with all the people and equipment easily accessible.
Pair Programming
Two programmers collaborate to solve one problem. Programming is not a spectator sport.
Planning Game
XP is an iterative development process. In the planning game, the customer and the programmers determine the scope of the next release. Programmers estimating the feature costs. Customers select features and package the development of those features into small iterations (typically 2 weeks). Iterations are combined into meaningful end user releases.
Refactoring
As programmers add new features to the project, the design may start to get messy. If this continues, the design will deteriorate. Refactoring is the process of keeping the design clean incrementally.
Simple Design
The design in XP is kept as simple as possible for the current set of implemented stories. Programmers don’t build frameworks and infrastructure for the features that might be coming.
Small Releases
Programmers build the system in small releases defined. An iteration is typically two weeks. A release is a group of iterations that provide valuable features to the users of the system.
Sustainable Pace
The team needs to stay fresh to effectively produce software. One way to make sure the team makes many mistakes is to have them work a lot of overtime.
Test Driven Design
Programmers write software in very small verifiable steps. First, we write a small test. Then we write enough code to satisfy the test. Then another test is written, and so on.
User Story
A User Story represents a feature of the system. The customer writes the story on a note card. Stories are small. The estimate to complete a story is limited to no greater than what one person could complete within a single iteration.

What Is Agile?

Agile/XP Principles

The Process

The Practices

To find out how your organization can become Agile,

take a look at our Agile services...