On Agile

Agile, as a mode of software development, has been running hot for several years now. Yet many people who bandy the word about have never even heard of the Agile Manifesto, much less understood it. How absurd is that?

The Agile Manifesto:

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.

To practice agile without knowing or understanding this manifesto is like waging a war with no regard for strategy and an obsession with tactics alone — the only possible outcome is failure. Recently, some teams at my company have begun trying Scrum, holding daily stand-ups and hardening them into a fixed process. This ignores the very first line of the manifesto: “Individuals and interactions over processes and tools.” Stand-ups are a fine thing — a tool that keeps everyone focused, surfaces wins, invites help, and advances the work in small, quick steps. But they presuppose respect for the individual (that is, every member of the team is fully empowered to act on their own judgment). If several overseers have to sign off on everything, you can hold stand-ups every hour and you still won’t be agile.

Another major misunderstanding of the manifesto is reactionary in nature. People who embrace agile tend to loathe the pathologies of the waterfall model with real passion, so they light up at the left-hand column and take it to be the whole of agile; and because they detest the right-hand column, they seize on agile as a pretext to attack it relentlessly. The items on the right are enormously valuable at all times — the manifesto merely wanted to draw attention back to the left, which had long been neglected. A common fallacy: “We’re using agile methods, so we don’t need a plan.” Sound familiar?

People who embrace agile also tend, almost as a rule, to overlook the twelve principles of agile software development:

1. Our highest priority is to satisfy the customer through continuous, early delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Notice how often the words “deliverable,” “working,” and “sustainable development” appear. Agile’s foremost goal is delivery — continuous delivery, from small increments of shippable functionality all the way to a polished final product. Teams that adopt Scrum, slice projects into iterations, and still ship once every six months are not agile, even if every single member has passed the “Scrum Master” certification.

Agile is about the rights and responsibilities of the individual; it emphasizes trust in and empowerment of the individual, because that is the wellspring of motivation. A good agile team, faced with an unresolvable disagreement over a design or a solution, should take this attitude: “I’ll keep my opinion to myself. This is your feature, so you have the right to build it the way you see fit — and to own the consequences.” “No problem.”

Complexity is the enemy of software. Complexity is equally the enemy of agile. Over-engineering is more terrifying than under-thinking. Under-thinking can be remedied in later development; over-engineering burns through vast amounts of effort, drags out the schedule, and adds complexity that never needed to exist.

A final thought from experience on putting agile into practice. Agile is the Way (道); implementation methods such as Scrum are the technique (术) — do not put the cart before the horse. Observe your team’s performance at regular intervals and choose the practices that suit it.

The startup I founded uses Scrum. At first it worked very well: daily stand-ups, an iteration every two weeks, a meeting at the end of each iteration to demo results and plan the next, a monthly retrospective. Everyone worked with gusto and high morale. But as the pace of development slowed, the practices began to sour — the stand-up in particular became a chicken rib: tasteless, yet a pity to throw away. By then the daily stand-up had become a hindrance; it should have been moved to every other day, or reshaped altogether. Embrace agile, but don’t let any single agile practice lock you in.