Agile is simply the course requiring the least amount of work
Posted by robkraft on January 6, 2011
I spent time today planning the features to include in our next four releases over the next two years. A small part of me kept telling myself that I was not being agile. I did this planning because I am using the plan to determine how to design some code for the next release. Am I right to believe that the capital “A” Agile purists would tell me I am doing something wrong?
My response to the purists is that I don’t care if I am an Agile purist or not, and I don’t care about Agile at all. I just want to produce the best software I can, and I will adhere to Agile when that seems to be best, but I will deviate from Agile when the pure Agile approach does not seem to be best.
For our next release, I need to design a specific pattern for hundreds business objects to follow. We will update our code generator to create all the business objects. The objects will be read-only versions in the first release, then editable objects in the second release, then objects that support asychronous methods in the third release. I had considered having all three versions inherit code from a single base class, but upon realizing that we would eliminate the read-only objects in the fourth release, I am chosing not to use this base class idea.
In short, I let an uncertain future determine my present design. But I argue that doing so is the correct thing to do, and that it is neither Agile, or not Agile. I must chose a design to implement, and the more information I have about the future the more likely I am to make a decision that minimizes the amount of work to be done. By looking into the future I am choosing a design that will actually save us one month of work in the first release, and will provide residual savings in subsequent releases. If I looked into the future and chose a design that ADDED months to the first release and provided no additional value my actions would not be Agile.
My conclusion is that you are being Agile when you select the course of action that requires the least work in the early stages, but that over the long term an Agile approach runs the risk of being less efficient.