“Individuals and interactions over processes and tools.”
Paying attention to individuals, the people on the team as opposed to roles in the process chart. Not all practices in software world are appropriate for every project, team and situation; while it is of utmost importance to understand the people in the team, how they work together and how each individual’s work impacts everyone else.
Although a process description is needed to get a group of people started, people are going to develop the program, and can go wrong when blindly following a process, or making use of tools that drive them to get faster an incorrect result.
But all the work is not carried out individually, being of relevance attending to the interactions between the individuals. New solutions and flaws in old solutions come to life in discussions between
people. The quality of the interactions matters, being preferable to use an undocumented process with good interactions than a documented process with hostile interactions.
“Working software over comprehensive documentation.”
There are binders full of complete and comprehensive software documentation sitting unopened on shelves all over the world. There is so much that can be documented in a software project, and it’s often difficult during the heat of the project to predict what’s going to be useful in the future, and what will gather dust. Because of that, a lot of teams—and especially their managers—will decide on a comprehensive approach, where every little thing must be documented, no matter whether or not
there’s a potential reader for the document.
On the other hand, a working system is the only way to measure the real work done built the team. Running code is ruthlessly honest, while documents showing the requirements, analysis, design, screen flows, sequence charts… are handy as hints to aid the team, together with their own experience, to guess what the future will look like
What does the word “working” really mean? To an agile practitioner, working software is software that adds value to the organization. It could be software that a company sells to make money, or it could be software that people who work at the company use to do their jobs more efficiently.
Valuing working software over comprehensive documentation does not mean that no documentation is needed; there are many kinds of documents that are very useful for the team. But it’s important to keep in mind that the people writing the documentation are often the same people who are writing the software.
Documents serve as markers in the game, used to build an image of the unreliable future. On the other hand, the composite act of gathering requirements, designing, coding, and debugging the software, reveals information about the development team, the development process, and the nature of the problem to be solved. Those things together with the running final result provide the only reliable measure of the speed of the team, the shortcomings of the group, and a glimpse into what the team really should be building.
“Customer collaboration over contract negotiation.”
There should not be a “us” or “them” when referring to people involved in the project. Independently of the task of building or providing requirements the team is performing, there should only be “us”. Both sides are needed to produce good software.
Although contracts are useful at times, collaboration strengthens development both when there is a contract in place and when there is none. Good collaboration can save a contract situation when it is in jeopardy. Good collaboration can sometimes make a contract unnecessary. Either way, collaboration is the winning element.
“Responding to change over following a plan.”
There’s an old project management saying: “plan the work, work the plan.” Unfortunately, if you work the wrong plan, you’ll build the wrong product. That’s why teams need to constantly look for changes, and to make sure that they respond appropriately when there’s a change in what the users need, or in how the software needs to be built. If the circumstances change, the project needs a new plan.
Building a plan is useful, and each of the agile methodologies contains specific planning activities. They also contain mechanisms for dealing with changing priorities, guaranteeing that the team has the time and peace of mind to develop working software.
How these values shape Agile
Out of these four values, the following points can be used to summarize the Agile basic tenets.
- Redefined roles for developers, managers and customers.
- No “Big Upfront” steps.
- Iterative development.
- Limited, negotiated functionality.
- Focus on quality, understood as achieved through testing.
The first tenet affects a fundamental feature of project development: the role of developers and managers. Agile methods redefine and limit the manager’s job by transferring many of the duties to the team as a whole, including one of the most important responsibilities: selecting tasks to be performed and assigning them to developers. It is possible to give a sociological interpretation of the agile movement as a “revolt of the cubicles”: the rejection of rigid, top-down, Dilbert’s-boss-like techniques for managing software projects. Programmers in the trenches — the cubicles — often resent these attempts as ignorant of the specific nature of software development. The Dilbert types know that documents and diagrams do not make a system: code does. Agile methods are, in part, the rehabilitation of code.
The redefinition of roles also affects customers, who in the agile world are not passive recipients of the software but active participants. Most methods advocate including a customer representative in the development team itself.
The second tenet is the rejection of “Big Upfront Anything”, a term used derogatorily for standard software engineering techniques involving extensive planning at the beginning of a project; the principal examples are requirements, to define the goals of the system, and design, to define its architecture. In the agile view:
- Requirements cannot be captured at the beginning of a project, because users do not know what they want. Even if one managed to write a requirements document, it would be useless because requirements will change through the project.
- Building a design upfront is a waste of time because we do not know what will work and what will not.
Instead of a requirements document, agile methods recommend constant interaction with the customer — hence the benefit of a customer representative in the team — to get both insights into the problem and feedback on what has been produced so far. Instead of design, the recommendation is to build the system iteratively, devising at each step the “simplest solution that can possibly work” (an Extreme Programming slogan) for the task at hand; then, if the solution turns out to be imperfect, improving its design through a process known as refactoring. Agile development, as a consequence, is iterative, time-boxed development.
The agile alternative to a requirements document is, at the beginning of each iteration, a prioritized list of functions from which the team will select for implementation the function that has the highest Return on Investment (ROI). In the absence of big upfront tasks, this choice will be made in successive steps, (e.g.: the “sprints” in Scrum) each taking a fixed time — a few weeks — hence “time-boxed”. The development thus proceeds by iterative addition of functionality.
The “negotiation” occurs at the step of choosing the functionality for each iteration. Just as it is impossible, in the agile view, to determine full requirements in advance, it is unrealistic to commit to both functionality and delivery time. With time-boxed development, any tradeoffs (“do you want it all or do you want it next month?”) will tend to be resolved in favor of the second criterion: if not all the functions planned for an iteration can be delivered by the deadline, it is the functionality that goes; the deadline stays. The missed functionality will either be reassigned to a subsequent phase or — if further analysis deems its ROI insufficient — dropped. This process of planning and adjusting requires constant negotiation with the customer.
The final tenet is the focus on quality, which in the agile view essentially means continuous testing (rather than other approaches to quality, in particular those based on design techniques, formal programming methodology, or whatever smacks of “Big Upfront”).
The agile approach has little patience with what it sees as the languid attention to quality in traditional development; it especially dislikes the practice of continuing to develop functionality even when the code already developed does not pass all the tests.
One of its contributions is to emphasize the role of a project’s regression test suite: the set of tests that must pass, including all tests that at some point did not pass and hence revealed faults that were then fixed. Regression testing has been known and applied for a long time, but agile methods have given this task a central place in the development process.