The Agile Principles

The twelve original Agile Principles are shown below, in addition to my interpretation of each one, for which I generalize towards product development, not just software. They form the basis of the Manifesto and were created by their authors after the meeting at Snowbird.

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

Success in product development lies in customer and user satisfaction. We generate value for customers and users early and often by delivering product increments that meet their needs. This principle opposes the traditional belief that success lies in following a detailed plan, delivering what was promised, on time and within budget.

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

Accepting change as natural in the product development process is what enables us to meet the needs of customers and users, and thus ensure that what is delivered truly brings value. As the product is developed, delivered, and used in short cycles, feedback from customers and users fuels its own development. Feedback that leads to changes in the product throughout its development is welcomed as an opportunity to increase the value delivered, and not as an undesirable event. In addition, we allow the product to assimilate market changes, enabling a quick response to them and thereby making it more competitive. This principle opposes treating change as an unwanted and costly enemy that, in the traditional definition of project management, should be prevented and avoided.

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

Delivering done and functional increments of the product frequently generates value with each delivery for the customers and users who receive them, besides allowing us to obtain feedback on what has been produced. In this way, we can incrementally adapt the product to the needs of these customers and users, reducing the risks in product development. This principle opposes the traditional practice of making a few or – at the limit – a single delivery of value, only at the end of the work.

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

Business people and the people who develop a product have the common goal of ensuring the creation of value for customers and users. To realize this goal, they must cooperate continuously throughout development of the product, interacting frequently. Ideally, they work side by side as members of the same team, or these roles may even be exercised by the same people. This principle opposes the antagonistic scenarios so common in product development, in which the business people – which often includes the customers themselves – and those who develop the product rarely collaborate or communicate directly. In general, they use documents for this purpose.

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

The product is built by people who must be motivated to do it well. The environment, support and trust needed to carry out this work are key factors to their motivation. This principle opposes the belief that products should be built around the best tools and processes, that people must be commanded and controlled when conducting their work, and that people are basically motivated, for example, by financial goals and incentives.

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

The best form of communication between members of the team that develops a product and between that team and the outside world is face-to-face communication. It is direct, synchronous, allows for instant feedback and adjustments, and is enriched by voice intonation, gaze, and body language, among other factors. When face-to-face communication is not feasible (in online work, for example), it is a good practice to make the best possible use of available technology to be as close as possible to face-to-face communication. This principle opposes the use of documents, email, telephone and teleconferencing, among others, as standard forms of communication in product development work.

7. Working software is the primary measure of progress.

Product development progresses to the extent that parts of the product that represent value are delivered to customers and users. This principle opposes the practice of measuring and reporting that there has been progress in product development due to the fulfillment of stages of a plan or the generation of artifacts that do not signify value, such as prototypes or extensive documents on plans and specifications. This false progress is usually shown through Gantt charts, progress bars, etc. that indicate percentages of completeness.

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

The team that develops the product works at a constant and sustainable pace. This becomes possible when this pace spreads throughout the chain, including the different stakeholders. When, for example, teams are required to commit to more work than they are capable of doing, it is common for them to use excessive overtime and the resulting overburden to meet their deadlines. These practices can lead to imbalances in the workflow, which end up generating dissatisfaction among the team, lower productivity, and lower quality in the developed product.

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

Developing a product with high quality based on technical excellence and a flexible design allows it to be more easily modified. Therefore, it is essential to maintaining its adaptability. This principle opposes the belief that in order to be agile in product development, quality must be sacrificed. In reality, the exact opposite occurs.

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

We avoid waste in product development by not doing work that is not necessary. Common examples of waste include implementing features that customers and users do not need, implementing unnecessarily complex solutions or anticipating future cases that will not necessarily materialize, planning in greater detail than we can ascertain at any given time, and the use or generation of unnecessary artifacts.

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

Teams with greater autonomy are more effective. These self-organizing teams work towards agreed goals but have the autonomy to decide how they will realize those goals. In this way, they become accountable for their results. The architecture, requirements and details of the product emerge from their work throughout the entire development of the product. In addition to talking about self-organization, this principle is opposed to the common practice of defining all the architecture and requirements of a product before beginning its development – the BDUF we talked about earlier. These should be defined progressively throughout the development of the product so they can emerge and evolve according to the reality that presents itself.

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

To become increasingly more effective, the team regularly inspects its ways of working, identifies points of improvement, and adapts accordingly, thereby promoting continuous incremental improvement. This is the inspection and adaptation that the team conducts in its work processes. The Sprint Retrospective meeting seeks to implement this principle when working with Scrum.