My Reservations about the Agile Principles

As a software developer, I’ve read the Manifesto for Agile Software Development countless times. It’s sort of a high-tech analog to the Hippocratic Oath for software people. Its full text is:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have 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

That is, while there is value in the items on
the right, we value the items on the left more.

It’s considered pretty non-controversial, and easily agreed upon. As it should.

But it’s based on a longer set of principles, the Twelve Principles of Agile Software. And here I take issue with a few points. But not because I necessarily disagree with them. Here I explain why, with some of my own commentary on the points I agree with completely.

Satisfy the Customer

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

Without a customer, software is useless. And I mean this in the broad sense–the customer is the consumer of the software, whether they, or anyone, has paid for the software. Open source software, as well as software you write only to be used by yourself, have customers. And if the customer isn’t served, everything else is irrelevant.

Welcome Change

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

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

Agile Development is centered around the concept of responding rapidly to change, in much the same way as the lean manufacturing and startup movements. Through rapid iterations and short feedback loops, I believe in the goal of turning change into an asset, rather than a liability.

“Business People” vs “Developers”

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

“I deal with the god damn customers so the engineers don’t have to. I have people skills; I am good at dealing with people. Can’t you understand that? What the hell is wrong with you people?” — Office Space

Here I take minor issue.

Actually, I agree with the principle. Where I disagree is with the premise: “Business people” and “developers” are two classes of people. Perhaps they often are in modern corporation, but this is not natural. A good developer is a business person, because writing good software is solving business needs, and solving business needs requires understanding business. In an ideal world, developers will be involved in every business aspect, from interviewing customers, all the way down to delivering the completed product. How this ought to look in practice is well beyond the scope of this post, but at the very least, the assumption that “business people” and “developers” must work together, rather than be the same people, must be challenged.

Motivated Individuals

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

I agree here. But most companies fail at this, even most “Agile shops.” Trust is very hard. Especially when you’re paying someone to do a job for you. What would it look like if your company truly trusted its developers? How would office hours be different? Expense reports? Working location? Job assignments?

Effective Communication

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

I have to wonder what the authors of the Agile Manifesto had in mind here. Surely they didn’t mean to dictate that remote teams should never be permitted. Or that there’s no place for emails or wikis.

I’m a strong believer in using the right tool for the job. And often this means face-to-face conversation. But often it means using other tools.

Where I and those I’ve worked with have been most burned in this area is in working for companies that always insist on using a single communication medium. Whether that is face-to-face communication, Slack, or the most brilliantly engineered distraction tool on the planet, one size does not fit all.

Working Software

Working software is the primary measure of progress.

I may disagree with this one. Taken to the extreme, it could contradict the first principle. The primary measure of progress should be delivering value to the customer (however “value” and “customer” are defined in your context). In some cases, the simplicity principle may even mean delivering less software, or no software at all.

Sustainable

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

Ahh! A burnout-free development environment! Who doesn’t want that?

Technical Excellence

Continuous attention to technical excellence
and good design enhances agility.

It’s hard to argue with this one. I’m almost left wondering why it made the cut. It seems curiously close to a tautology.

Simplicity

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

Deleting code I had previously written is one of the most satisfying experiences I ever have as a programmer.

Self-Organization

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

I see this as inseparably linked with the principle of motivated developers. As Daniel Pink explains in his book Drive: The Surprising Truth About What Motivates Us autonomy is a necessary ingredient for motivation.

Reflection

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

I like this principle. I don’t like the formulaic “scrum retrospective”, which is so often done every 2 weeks, then a check-box marked. The key here isn’t “regular intervals”, the key is “tunes and adjusts its behavior.” At least in my experience, this has too often been forgotten. But I don’t blame Agile for the poor execution.

Conclusion

I believe the Agile Manifesto has done a lot of good in the world of software development since it was formulated in 2001. But I think we need to engage in reality checks from time to time, and challenging things taken for granted is healthy. In the spirit of Agile, this is my contribution to the effort of “At regular intervals, reflecting on how to become more effective.”

Which points would you tune and adjust?

One Comment

  1. Let me respond to the points you disagree with:

    To discuss a difficult topic is most effectively done face-to-face. No delay in the connection using Skype and related interventions. However that doesn’t mean that tools can’t fill in for simpler conversations at times. Also remember that technology has improved since the manifesto was written. Besides, also small teams with less communication lines is part of this priciple. And recurring structured communication like the daily scrum.

    The working software principle is not about how much to deliver, more about what the deliverables are. Designs and plans are not an indication of progress, software is.

Leave a Reply

Your email address will not be published. Required fields are marked *