Agile in Practice – Four Reasons to "Build for Today"

Agile in Practice – Four Reasons to "Build for Today"

One of the philosophies of Agile projects is to "build for today." In other words, you should design, build and test only what is necessary to meet the needs of the user stories that are selected in the current iteration.

In some respects this goes against the intuition of many team members that feel it is more efficient in the long-term if they take into account potential future requirements. The thought is that you should build to support this future functionality "while you are there" and then later when the requirement is actually selected you can finalize the work with much less effort.

In the Agile model this is generally seen as a false tradeoff for four reasons.

1. First, the time it takes to design, build and test to support future features will mean that you cannot get as much done in the current cycle. You are supporting fewer current, concrete, high-priority requirements in exchange for vague, distant        potential future requirements. This is not seen as a good trade-off.
2. Second, it is possible that this extra, future functionality will never be needed or requested. The customer may have requested this future functionality in a traditional project, but in an Agile project, the difference between "wants" and "needs" is much more focused. Who knows if the extra functionality will make it into a future iteration? The world is full of systems functionality that is written into programs but never utilized.
3. Third, it is very possible that you may not implement the future requirement correctly anyway. The product owner will not discuss it or test for this future condition. Even if a future requirement seems simple and fully understood, it is possible for misunderstandings and errors to occur. Then you are out-of-synch trying to test and debug problems that should not even be a part of this iteration. Each cycle will also have its own challenges. You don't need to compound things by introducing problems that are not a part of this release.
4. Fourth, if the extra functionality is needed in the future, it will have its turn in a future cycle. When the functionality is chosen, the work will be constructed and tested. In an Agile project, you will likely visit the same sections of the solution multiple times. You don't have to worry about building extra functionality "while you are there" because it is very likely you will "be there" many more times before the project is completed.

This philosophy should be applied for process functionality, performance, security, etc. The "build for today" approach is also an example of "minimally sufficient," which is another Agile philosophy. You want to make sure that you do everything required to support the customer needs, but no more.