After Ten Years: One Person's Stance on the Agile Manifesto

I write a lot about ALM and agile, so I'd like to state my views of the Agile Manifesto—What does it imply? What should it imply and what shouldn't it imply—just so that everyone knows where I stand.

According to the Agile Manifesto, agile methods 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

Now, although I whole-heartedly buy into agile methodology where appropriate, there are various interpretations of the manifesto that tend to de-emphasize processes and tools, documentation, and following a plan. I'd like to spend a few paragraphs ensuring we're on the same page.

Individuals and Interactions over Processes and Tools
For me, this is a tough one, because I believe it should be primarily the processes and tools that facilitate the capabilities of individuals and their interactions. Interactions are important, but sometimes it's better not to have them.

For example, if I can peer review code and add my comments online through the tools, I'm sure my review is accurately captured. And I can do the review right away, rather than waiting for a scheduled meeting. On the other hand, if there are issues that arise that require a meeting, it’s important that a meeting is held.

At the same time, I need to ensure that my review comments follow a proper protocol. I've seen reviews, live and written, fall into a feud. Individuals are important and should not be attacked. If the comments are public (i.e., within the product team), there's less chance of a feud happening—comments are more objective, as are responses. So the tools that make them public are important.

Similarly, I don't need an interaction to tell me what problems have to be fixed. As long as they are assigned to me and have well-formed problem descriptions, I can fly with them. However, if there's ambiguity, I need to interact. The interactions may be live, but sometimes a better solution is a Q&A addendum to the problem report to document the clarification for future reference.

So, to me, this one is better written: effective tools and processes that enhance the productivity of individuals while encouraging interactions only as necessary. Tools and processes are important. They help ensure that interactions are more effective.

Working Software over Comprehensive Documentation
Software has limited value if I don't know the extent of what it can do. In some cases, an overview is good (e.g., word processing software), because I'm familiar with the application. In other cases, I need comprehensive documentation. This applies equally well to requirements and to user guides. Defining and learning a new programming language is an excellent example of where comprehensive documentation is key, both up front and after the fact. A compiler that works well supporting some of the language features is less important if I don't understand those features. Also, it’s a waste to have an open source application that has all sorts of features that I can't use because they're not documented.

One of the key issues here is that this item tends to support a view where coding can get underway immediately. This results in less up-front architecture and often in a lot of rework. The push is to get something working fast, rather than to document a good architectural framework on which to build.

Get your architecture right so that you can put working software first. And be critical of the working software. If it's going to require more documentation than users feel it should, perhaps the spec should be simplified. "Why do I have two different panels coming up instead of one?" "Why can't I just click on this to get the information?" "Why is this not consistent with the way other features work?" Working software is great for bringing out these questions. Specifications can be just too wordy to accomplish the same, especially those where 80 percent has been cut-and-paste and the stakeholders just fill in some blanks.

Customer Collaboration over Contract Negotiation
I agree with this. Almost always. It's better for the customer: "You said you wanted this, but if we do this instead, not only do you have that capability—perhaps a bit different than you wanted—but you also get X, Y, and Z, which you didn't ask for." "Wow, that would be great," says the customer. It comes down to this: If you're an expert in building software in your niche field, you understand the customer requirements better than the customer. A few iterations, and the customer begins to appreciate this and wants more.

Still, at times the customer is on a tight budget and timeline or has hard requirements based on external integration specs. So contracts still have their place. But if you told the customer that you could do 80 percent of his features for 50 percent of the cost (30 percent is profit, that's why it's not the 80/20 rule), your customer would likely say, “Yes, let's start there and then we'll look at how we get the rest of the functionality we need, perhaps in the next release.” More than likely, a lot of that functionality either won't be needed or becomes obsolete based on your architecture. For example, I wouldn't dream of integrating CM+ with a database vendor's reporting language just because the customer asked for it or is familiar with it. I'd show them the capabilities in the CM+ architecture that exceed their requirements, and then ask them if they really still need it. Of course, if it's needed to meet a blind requirements checklist, we'd show them how easy the integration is anyway, even though we wouldn't expect them to ever use it. Collaboration is the way to go.

Responding to Change over Following a Plan
Planning is good; it gives you a baseline. The problem is that if you plan out further than you can see, your plans will become heavy millstones. That's what's good about Agile—you plan out in advance a couple of iterations or so (after establishing a good architecture), and then you continue to run on a priority basis, based on what the customer tells you (and often the customer is the market). I'm sure many mobile device companies were working on some nifty pointing devices prior to seeing the iPhone. That changed the game. If they didn't change and respond, they were toast.

At the other end, if you have a lot of features that are highly interactive (i.e., impact one another), then this could complicate your verification cycle. As you reach the 75 percent completion point, you may want to carefully plan your iterations—or at least your release backlog—in such a way as to minimize the chances of destabilization or reduced quality. Yes, your continuous integration is going to help you with quality, especially in light of changing requirements, but at some point, you have to spend time to make sure that your product is 100 percent ready, not just stable enough to keep improving.

Responding to change is following a plan—it's just a more fluid plan that focuses on priorities more than dates and on minimizing acceptance risk more than content completion risk. Your customer collaboration will help you deal with any specific risk items adequately.

So, those are my views of the Agile Manifesto. Maybe you agree 100 percent, but more likely you don't. I welcome your comments and will respond to them in a timely fashion.