Nowadays, the number of agilists (people who attempt to adhere to the values and principles of agile) has grown into the millions, and surveys confirm that the majority of software developers around the world practice at least some of the “core agile practices.” Here, I will describe the agile basics using my own “seven dimensions of software projects.”

1. People
First and foremost, agile recognizes that people are unique individuals instead of replaceable resources and that their highest value is not in their heads but in their interactions and collaboration. Agile calls for small teams, where different roles (developers, designers, testers, etc.) form cross-functional units, preferably located in the same room. These teams are then required to self-organize, meaning that no method or process is imposed on them. They are trusted to get the work done in ways that they think are best, assuming they know how to do that, with accountability for their results.

2. Functionality
Agile understands that the best products are created when customers are directly involved with the teams creating them. A team collaborates with the customer (or a customer representative) in order to maintain and continually reprioritize an ever-changing backlog of features. These features are described in a very concise format, or “inch-deep,” and more extensive exploration and documentation only starts as soon as the features are selected for immediate implementation by the team. Simplicity is the key to good design of each feature, and after their implementation, the usefulness of features is immediately verified by the customer.

3. Quality
For successful products, a focus on quality is crucial, and, therefore, technical excellence finds itself at the core of agile. It is achieved through test-driven development (writing test code before writing production code), code reviews (often through pair programming), definition of done (checklists), iterative development (adapting code due to changes or new insights), and refactoring (improving code even when no features have changed). Agilists recognize the need for emergent design, meaning that the best architectures are not defined (or are defined only in a basic form) up front and are allowed to further emerge while developing a product.

4. Tools
Agilists believe that tools are among the least important contributors to successful products, yet plenty of tools are described and promoted in agile literature. Experienced agile teams prefer tools for daily builds, continuous integration, and automated testing. Agile software development needs teams to be motivated, but repetitive tasks are boring, not motivating, and so they should be automated. Many agilists also call for supportive environments, like open office layouts, and tools that “radiate” information, like big task boards and burn charts. In an agile context, tools are meant to strengthen motivation, communication, and collaboration in a team.

5. Time
Agile has a special relationship with time. In agile projects, delivery dates and deadlines, like budgets, can be chosen almost arbitrarily. Software is produced in very short time frames—often in timeboxes or “sprints”—and delivered in many incremental releases, where each release is a potentially shippable product. This enables business owners to take control of timing, moving release dates back and forth, depending on what features they want to make available when. In the meantime, the team always strives for a sustainable pace so that they can maintain their development speed almost indefinitely.

6. Value
One of the primary reasons the Agile Manifesto was crafted was to address the need to respond to change. The environment is never static. Features that were valuable yesterday may be useless tomorrow, including the features already successfully delivered to users. Agilists try to cope with this challenge by nurturing short feedback and delivery cycles. Frequent product releases are meant not only to invite feedback from the environment and feed the findings back into the development process, but also to deliver new and updated features to users as soon as the need is detected, thereby optimizing the features’ business value.

7. Process
Even though agile suggests a “people over process” paradigm, this doesn’t mean that process is unimportant—far from it. Some essential processes in an agile context include minimal (or “rolling-wave”) planning, daily face-to-face communication (often in the form of stand-up meetings), and measurement of progress by evaluating working software (features accepted by the customer). Agilists also acknowledge the need for continuous improvement, whereby the processes themselves are repeatedly evaluated and tuned, through regular reflection or retrospectives.

Conflict
These are what I believe to be the fundamentals of agile. And, of course, they are just my words. Some agilists will disagree with the brief descriptions I have offered here, but that is also part of being agile. I might even call “conflict” the eighth dimension of agile software development. Internal conflict is a natural aspect of complex systems and a prerequisite for creativity and innovation. It is a great privilege to be among people who enjoy few things more than trying to improve on one another.

 This article is adapted from the book Management 3.0: Leading Agile Developers, Developing Agile Leaders  by Jurgen Appelo, published by Addison-Wesley in Mike Cohn’s Signature Series.