Agile software development is all about the tools

The above statement, is the equivalent of putting my foot into my mouth, and committing social software suicide. The reason is that the Agile manifesto, repeatsĀ “Agile is not about the tools”, in literally every single paragraph. So when I claim what I do in the header of this article, I literally disagree with every single software development theory, that has ever been put forth – And every single software architect guru, that has walked this Earth in recent times. However, I can prove that I am right, and I intend to do so in this article.

At the heart of “being Agile”, is the ability to be customer driven. This implies that the customer is allowed to make all the important decisions of what features the end software should have. In fact, this is the sole motivation for why system developers seeks to become “more Agile”. When the customer gets to decide how the end product ends up, the software is able to reach its goals. When the customer is not able to influence the end result, we might just as well start flipping burgers, since we don’t provide the expected value for our customers – And our customers will end up leaving us, and go to somebody who is able to deliver what the customer actually wants.

If you wanted to buy a car, and the seller gives you a horse, how would you feel?

The above is such a self evident fact, that arguing about it, is meaningless. If you create a statue out of granite, then once it starts taking shape, there is no way to really modify it. If you instead start out with building blocks, or “clay” to use an analogy – You can always go back and change it. Hence arguably, we have already proven that “Dynamic programming languages is a better tool for being Agile than statically compiled languages, and since programming languages are tools, well, you get the point” …

The Agile manifesto, and its different methodologies, seeks to “facilitate for change”, by creating all sorts of theories and methodologies about how to manage your code. For instance, eXtreme Programming taught us that we need Unit Tests, since this allows us to change our code, without introducing bugs. The objective of course, is to change your system. The Unit Tests from this perspective, is simply a tool, that allows you to safely apply your change.

Hence, arguably, we have already implied that XP is all about the tools

However, we can bring this much further. Imagine a system, where its core developer only creates the core building blocks, and the process of tying these together, is left for the customer – Under guidance from the main developer of course. Such systems facilitates for becoming Agile, to an extent impossible to imagine for most system developers. Then imagine a system where its core developer, can apply most changes, faster than the customer can communicate these changes – Facilitating for that its core developer(s) can modify the system, in a conversation with the customer, showing the results of the customers needs, seconds after they have been communicated? Would that be “Agile”?

Well, let me show you a tool which facilitates for that.

Then come back to me and argue that “Agile is not about the tools”

Facts are, Agile is only about the tools. And the better tools you start out with, the more Agile you allow yourself to be. And the more Agile you allow yourself to be, the more happy customers you will have. And the more happier customers you have, the more happy you will become, and so on …

Agile is all about the tools!

Magic menu is a new way of communicating between computers and human beings, allowing humans to rapidly “configure” what they want the computer to do, once some “button” or “menu item” has been selected. Read the following article, and try to explain to me how the Magic menu is not a tool, and how it does not facilitate for becoming more Agile – And I will eat the foot that is now in my mouth, if you can …