Agile Values

“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.

  1. Redefined roles for developers, managers and customers.
  2. No “Big Upfront” steps.
  3. Iterative development.
  4. Limited, negotiated functionality.
  5. 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.



Chapter 5: The Second System Effect

The second-system effect proposes that, when an architect designs a second system, it is the most dangerous system they will ever design, because they will tend to incorporate all of the additions they originally did not add to the first system due to inherent time constraints. Thus, when embarking on a second system, an engineer should be mindful that they are susceptible to over-engineering it (*).

Adde parvum parvo magnus acervus erit.
{Add little to little and there will be a big pile.}


If one separates responsibility for functional specification from responsibility for building a fast, cheap product, what discipline bounds the architect’s inventive enthusiasm?

The fundamental answer is thoroughgoing, careful, and sympathetic communication between architect and builder. Nevertheless there are finer-grained answers that deserve attention.

Interactive Discipline for the Architect

When a construction architect devises a project against a budget, it usually happens that the initial offer has to be re-designed iteratively in order to fit contractor’s bids.

An analogous process governs the architect of a computer/programming system, with the advantage of getting bids from the contractor at many early points in his design, almost any time he asks for them. He usually has the disadvantage of working with only one contractor, who can raise or lower his estimates to reflect his pleasure with the design. In practice, early and continuous communication can give the architect good cost readings and the builder confidence in the design without blurring the clear division of responsibilities.

The architect has two possible answers when confronted with an estimate that is too high: cut the design or challenge the estimate by suggesting cheaper implementations. This latter is inherently an emotion-generating activity. The architect is now challenging the builder’s way of doing the builder’s job. For it to be successful, the architect must

  • be aware that he suggests, not dictates : the builder has the inventive and creative responsibility for the implementation
  • be flexible and always be prepared to suggest a way of implementing anything he specifies, and be prepared to accept any other way that meets the objectives as well
  • deal quietly and privately in such suggestions
  • be ready to forego credit for suggested improvements

Self-Discipline — The Second-System Effect

When an architect first designs a work, it starts from the ignorance of not knowing what is to be done, so he pays careful attention, controlling every aspect, taking out concepts and feature not really relevant, but stores them for a future when they might be used.

The architect faces no a second system to design, which is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a “big pile” of functionalities where most of them are rarely used.

The second-system effect has another manifestation somewhat different from pure functional embellishment. That is a tendency to refine techniques whose very existence has been made obsolete by changes in basic system assumptions.

How does the architect avoid the second-system effect? Well, obviously he can’t skip his second system. But he can be conscious of the peculiar hazards of that system, and exert extra self-discipline to avoid functional ornamentation and to avoid extrapolation of functions that are obviated by changes in assumptions and purposes.

A discipline that will open an architect’s eyes is to assign each little function a value: capability x is worth not more than m bytes of memory and n microseconds per invocation. These values will guide initial decisions and serve during implementation as a guide and warning to all.

How does the project manager avoid the second-system effect? By insisting on a senior architect who has at least two systems under his belt. Too, by staying aware of the special temptations, he can ask the right questions to ensure that the philosophical concepts and objectives are fully reflected in the detailed design.

The Agile Manifesto

In February 2001, seventeen software developers met at the Snowbird resort in Utah to discuss lightweight development methods, among others Jeff Sutherland, Ken Schwaber, and Alistair Cockburn. Together the seventeen published the Manifesto for Agile Software Development, in which they shared that, through their combined experience of developing software and helping others to do it, they had 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

While the secondary concerns were important the primary concerns were more critical to success.
By these terms, they meant:

Individuals and interactions
Self-organization and motivation are important, as are interactions like co-location and pair programming.
Working software
Working software is more useful and welcome than just presenting documents to clients in meetings.
Customer collaboration
Requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
Responding to change
Agile software development methods are focused on quick responses to change and continuous development.

Some of the authors formed the Agile Alliance, a non-profit organization that promotes software development according to the manifesto’s values and principles. Introducing the manifesto on behalf of the Agile Alliance, Jim Highsmith said,

The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as “hackers” are ignorant of both the methodologies and the original definition of the term hacker.

— Jim Highsmith, History: The Agile Manifesto

Agile software development principles

The Manifesto for Agile Software Development is based on twelve principles:

  1. Customer satisfaction by early and continuous delivery of valuable software
  2. Welcome changing requirements, even in late development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

from Wikipedia

Chapter 4: Aristocracy, Democracy and System Design

This great church is an incomparable work of art. There is neither aridity nor confusion in the tenets it sets forth. . , ,

It is the zenith of a style, the work of artists who had understood and assimilated all their predecessors’ successes, in complete possession of the techniques of their times, but using them without indiscreet display nor gratuitous feats of skill.

It was Jean d ‘Orbais who undoubtedly conceived the general plan of the building, a plan which was respected, at least in its essential elements, by his successors. This is one of the reasons for the extreme coherence and unity of the edifice.


Conceptual Integrity

The typical situation for a cathedral building is being made during several generations by several builders, where each period shows the ideas and “improvements” of those in command at that moment.

The Reims Cathedral is the counterexample: the building integrity was achieved by the self-abnegation of eight generations of builders whom sacrificed some of his ideas in benefit for the construction pure design.

Even though they have not taken centuries to build, most programming systems reflect conceptual disunity far worse than that of cathedrals. Usually this arises not from a serial succession of master designers, but from the separation of design into many tasks done by many men.

Conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

Achieving Conceptual Integrity

The purpose of a programming system is to make a computer easy to use.

Ease of use is enhanced only if the time gained in functional specification exceeds the time lost in learning, remembering, and searching manuals. With modern programming systems this gain does exceed the cost, which did not happen in software development old days. Because ease of use is the purpose, the ratio of function- conceptual complexity is the ultimate test of system design. Neither function alone nor simplicity alone defines a good design.

For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness.

It is not enough to learn the elements and rules of combination; one must also learn the idiomatic usage, a whole lore of how the elements are combined in practice. Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata.

Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity.

Aristocracy and Democracy

Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. Schedule pressures, however, dictate that system building needs many hands. Two techniques are available for resolving this dilemma.

  • Division of labour between architecture and implementation.
  • The Surgical Team structuration

The separation of architectural effort from implementation is a very powerful way of getting conceptual integrity on very large projects. Complete and detailed specification of the user interface.  (For the entire system it is the union of the manuals the user must consult to do his entire job).

The architect of a system has to bring professional and technical knowledge to bear in the unalloyed interest of the user, as opposed to the interests of the salesman, the fabricator, etc.

“Where architecture tells what happens, implementation tells how it is made to happen.”

In regard to the deeply emotional question of aristocracy versus democracy:

  • Are not the architects a new aristocracy, an intellectual elite, set up to tell the poor dumb implementers what to do?
    • Yes, in the sense that there must be few architects, their product must endure longer than that of an implementer, and the architect sits at the focus of forces which he must ultimately resolve in the user’s interest. If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology.
    • No, because the setting of external specifications is not more creative work than the designing of implementations. It is just different creative work. The design of an implementation, given an architecture, requires and allows as much design creativity, as many new ideas, and as much technical brilliance as the design of the external specifications.
  • Has not all the creative work been sequestered for this elite, leaving the implementers as cogs in the machine?
  • Won’t one get a better product by getting the good ideas from all the team, following a democratic philosophy, rather than by restricting the development of specifications to a few?
    • Not only the architects will have good architectural ideas. Often the fresh concept does come from an implementer or from a user. However, the conceptual integrity of a system determines its ease of use. Good features and ideas that do not integrate with a system’s basic concepts are best left out.
    • If there appear many such important but incompatible ideas, one scraps the whole system and starts again on an integrated system with different basic concepts.

The external provision of an architecture enhances, not cramps, the creative style of an implementing group. They focus at once on the part of the problem no one has addressed, and inventions begin to flow. In an unconstrained implementing group, most thought and debate goes into architectural decisions, and implementation proper gets short shrift.

What Does the Implementer Do While Waiting?

“It is a very humbling experience to make a multimillion-dollar mistake, but it is also very memorable”

When it is proposed that a small architecture team in fact write all the external specifications for a computer or a programming system, the implementers raise three objections:

  • The specifications will be too rich in function and will not reflect practical cost considerations.
  • The architects will get all the creative fun and shut out the inventiveness of the implementers.
  • The many implementers will have to sit idly by while the specifications come through the narrow funnel that is the architecture team.

In the computer systems business the pace is quicker than in construction (where design comes first, building comes after), and one wants to compress the schedule as much as possible. How much can specification and building be overlapped?

The total creative effort involves three distinct phases: architecture, implementation, and realization, which can in fact begun in parallel and proceed simultaneously. Meanwhile, on the realization level there is much to be done also. Programming has a technology, too. Much work must be done on subroutine conventions, supervisory techniques, searching and sorting algorithms.

Conceptual integrity does require that a system reflect a single philosophy and that the specification as seen by the user flow from a few minds. Because of the real division of labour into architecture, implementation, and realization, however, this does not imply that a system so designed will take longer to build. Experience shows the opposite, that the integral system goes together faster and takes less time to test. In effect, a widespread horizontal division of labour has been sharply reduced by a vertical division of labour, and the result is radically simplified communications and improved conceptual integrity.