Why Agile isn’t the answer.

For years I was a proponent of Agile techniques. Of course I say that knowing that the word Agile is about as ambiguous as the word God. The one thread of consistency in how Agile works out in practice is the reason why it’s not the answer to managing software development.

In the 12 principles of the Agile Manifesto, there’s a line that reads:

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

Seems benign. In fact, at first glance this seems like sage advice. Touching base daily, when doing anything, seems like a good idea. Assuming that work is being done daily.

The problem is the first part of this statement: Business people and developers. Language often conveys what is lurking deep in the mind. Like when someone decries being divisive while simultaneously using the words them and us instead of we.

Developers are business people. The only way the statement in the Agile principles makes sense is to suggest that they’re not. That developers are simply people that hammer out software. Which assumes that developers deliver software that is inherently valuable to business people. Business people that derive value directly from the software.

And this underscores the issue with agile in practice, it still assumes that software is inherently valuable. When in reality software is not the point. Software is a means to an end.

When one realizes that software is a tool, a means, then one focuses on developers as business people. Business people that are deeply aware of the value that is to be created. Value that could be derived with or without software.

Until developers are seen as business people, working to create value for customers just like every other person in the business, there will always be a gap between what the software does and the value that it provides to customers. That gap will never be filled with working together daily with business people barking orders for user stories–a euphemism for specifications–at developers.

The oft missing component, no matter what approach is taken toward implementation, is neglecting to determine what one should do before they go about doing it. You’ll have the same issues of handoff with any Agile practice if you have business people responsible for WHAT while developers are only responsible for HOW. WHAT, in a business, is creating value for customers. HOW, well, that’s any ethical way to get the job done.