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

Summary:
Joe Farah often writes about ALM relative to agile. In this article, he lays out his views on the Agile Manifesto specifically. From collaboration and clear communication to the focus on individuals over tools, Joe covers what works, and what he thinks could work better.

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.

User Comments

1 comment

About the author

Joe Farah's picture
Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com