My Reservations about the Agile Principles
October 18, 2017
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 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.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.
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?
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 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.
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?
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--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.
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.
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.
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?
That won't work here, we're different
What thing would you like to see work for you, but simply won't "because you're different"?
Don't try fix everything at once
Most teams have many problems that could be fixed. But not all should be fixed. At leat not yet.
Improve your software delivery