In today's fast-paced world, companies need to deliver more from development projects – meaning faster development time, increased productivity, better return on investment, higher quality work, and satisfied customers. With the turn of the century a new breed of software development methodologies, coined “Agile” was born. Agile, in its simplest form, is a mindset that helps teams maintain a focus on the rapid delivery of business value. The Agile mindset is defined by values, explained by principles and manifested with practices.

Is Agile Just Another Process ?

Many people may think that agile is just another software development process. Although that is true to a degree, there is a lot more to agile than just a process or just a set of practices. Agile (or agility) is more of a mindset—a way of thinking about software development. This agile mindset can be applied to any process using any set of practices. The best way to illustrate our understanding of agile is through the following diagram. We will explain the diagram in each of the sections in this article.

Figure 1. Visualization of the Agile values, principles and practices and the relationship between them.

The Inner Most Circle: T he Need to Respond to Constant Change.

Today the market is moving quickly, and as a result, the software development lifecycle needs to be flexible enough to enable organizations to seize new and emerging market opportunities before their competitors do. To reach the desired ability to respond to constant change, your software process needs to focus on what is truly important. Similar to the way you pack light when you’re going to backpack around Europe, your process needs to be light. You need to increase everything in the process that adds value to the end goal and decrease everything that doesn’t add value. Agile values attempt to highlight what adds value in a software development process.

The Second Circle: The Agile Values.

In 2001, a group of authors wrote a document called the Manifesto for Agile Software Development, with a goal of identifying the values that yield the most benefit to a software development process. Let’s look at the manifesto, which is available online at http://agilemanifesto.org/:

We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value: 

Individuals and interactions over processes and tools 

Working software over comprehensive documentation 

Customer collaboration over contract negotiation 

Responding to change over following a plan 

That is, while there is value in the items on the right, we value the items on the left more.

When people first read the manifesto they immediately agree with the stated values or they hesitate. The hesitation usually comes from the perception that an agile methodology throws away the items on the right (processes, tools, documentation, contracts, and planning). This is completely false. The manifesto is saying that the items on the right do add value to the development process but the items on the left (interaction between individuals, developing working software, and so on) provide more value to the process. The manifesto is trying to point out that organizations traditionally put a huge emphasis on the items on the right, such as processes and tools, and neglect the items on the left, such as the interaction between individuals. An agile mindset promotes the items on the left while maintaining the level required for the items on the right. Let us re-emphasize that an agile process can and sometime should contain some of the items on the right; but you need to make sure that each of those items adds indispensible value to the project.

The Third Circle: The Agile Principles

Moving to the layer that surrounds agile values in Figure 1, let’s consider the agile principles. The Manifesto for Agile Software Development defines a set of 12 principles that represent the characteristics or inherent traits of an agile process:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

As obvious as this principle may seem, it’s often violated in traditional software development. It’s important to remember that customers are asking you to deliver working software that adds value; they don’t want a prototype or a set of documents. The earlier you can start delivering working software, the earlier you can begin satisfying your customer.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Your customers are competing in a dynamic market, and therefore they may have to change the requirements for their software in order to gain a competitive advantage. It is important to note that you should welcome changing requirements, but no one said this change is free.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Have you ever shown your customer software for the first time and received no feedback? In most cases, you receive feedback—sometimes minor, but usually major. The trick is to deliver software early so that you can get feedback early. This early feedback can save you re-work down the road.

4. Business people and developers must work together daily throughout the project.

This principle is careful to say business people and not the customer. In most cases, it would be impractical to work with the customer on a daily basis; but generally there are multiple business proxies. These proxies may not know everything about the customer’s wants and needs, but they usually know more about the business needs than the developers do. These proxies may be analysts, product managers, or program managers. The key is to maintain constant communication between the developers and the business people to ensure that the project never goes off track—not even for a day.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Remember, people aren’t resources. Software development is different from manufacturing. Software development is more of an art. Project teams need to be motivated and trusted. If you have motivated team members they will find a way to give you their best; and that’s what an agile process needs—everyone’s best.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Instant messaging or the telephone should never replace face-to-face communication. A lot of context is lost in communication over email and instant messaging—not to mention the fact that ambiguity increases with nonverbal communication. Face-to-face communication also lets you run with less formal documentation.

7. Working software is the primary measure of progress.

In most cases the customer is primarily interested in working software. So why would you measure progress in terms of anything else? Today, the progress of most software development efforts is measured in terms of their plan. When requirements are complete, the managers say the project is 30 percent complete. In a plan-driven world, this may be correct; but in a value-driven world, where the value is the working software, the project is 30 percent complete when 30 percent of the required functionality is coded, integrated, tested, and deployed. This is a fundamental difference between the agile value-driven world and the traditional plan-driven world.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

In traditional development, the team often has to work late toward the end of a project, although at the beginning of the project they may have taken 2-hour lunch breaks. This is primarily due to the way project activities are distributed across the project’s lifecycle. There isn’t much for developers to do at the beginning of the project, but at the end everything is put on their shoulders because of tight delivery schedules. With agile development, you deliver every two weeks or so, and development begins with the first iteration. Efforts are distributed more consistently throughout the project lifecycle, which leads to a constant development pace for the team.

9. Continuous attention to technical excellence and good design enhances agility.

A successful gymnast needs strong muscles. Similarly, technical excellence is an essential enabler for a truly agile software development process. For example, extensible designs and architectures make it much easier to build the product in an evolutionary manner. Automated testing frameworks are needed to ensure that refactoring one part of the system doesn’t affect other parts. Continuous integration is essential if you want assurance that your software is working after every change.

10. Simplicity—the art of maximizing the amount of work not done—is essential.

No code means no bugs. The more code you write, the more bugs your code may have. If something isn’t essential to the product, then don’t build it. Some developers tend to develop massive underlying frameworks and infrastructures in the system under the assumption that those elements may be needed in the future. The key is simplicity: try not to develop anything that isn’t essential to the features you’re developing now. Remember, the more time you invest in anything, the more you get attached to it. This attachment makes it harder to accept the fact that you don’t need a piece of code or that you need to change it.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

In traditional software development, analysts write requirements, and architects lay out the architecture of the system. Then the requirements and architectures are communicated to the team in a document. In the agile world, we encourage teams to self-organize. True self-organization involves giving the whole team the task and asking them, as a team, to complete the task without specifying who should do what—they’re left to self-organize. It will naturally occur that architects will lead the discussion when it comes to architecture, but now everyone is free to challenge them and suggest new ideas that may enhance the architecture the architects would have come up with on their own. This form of collaboration also increases the knowledge transfer within the team.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

We believe this is probably the most important principle of agility. The idea of always reflecting on what you’re doing and trying to figure out better ways to do things is the essence of continuous improvement. Without continuous improvement, people and organizations remain at a status quo. If you adopt only one thing that will make your process better, regularly reflect on your process as a team. You need to identify what you’re doing well and continue doing it, and you need to identify what you’re doing poorly and improve it.

The Last Layer: The Agile Practices

The last layer in Figure 1 represents the agile practices. These are activities that are used to manifest or implement the agile principles and values. There are numerous agile practices, such as user stories, test-driven development, pair programming, daily stand-up meetings, and so forth. But no specific set of agile practices is defined—it’s anti-agile to say that there is a defined set of practices and that no new practices can be created. Organizations create different agile practices or tailor existing agile practices to address specific organizational or team needs. Teams may also need to be creative and come up with new agile practices to achieve agility while adhering to organizational constraints. Known agile development methodologies like Extreme Programming (XP), Scrum, Lean, and Feature Driven Development (FDD) consist of a set of agile practices that have a certain synergy. Some methodologies, like Scrum, focus more on agile practices related to project management; others, like XP, focus more on technical agile practices. No methodology is better than the other; it all depends which works best in your environment and within your constraints.

Benefits for Adopting Agile

Numerous surveys and case studies show that the organizations adopting agile development and agile management practices realize a significant gain in various business values, such as:

Companies that adopted agile have experienced