Agile in Practice – Building for Today versus Tomorrow
TenStep's Method123 templates blog, reproduced for you below, provides four reasons to "build for today", supporting and reinforcing the agile philosophy.
Agile is all about acknowledging a number of realities about the short and long term in the development of software.
- There may not be a "long term", as conditions change so quickly. Since the further from the present we look, the more difficult it is to forecast. Therefore, we are better off doing a good job in the short run.
- There may not be a long term if you don't deliver in short term! It's only by doing something successful now that you will even have - or even create - the opportunity down the road.
- Often times the long term is so murky looking now that you know that eventually it will look much clearer. The short term work can be designed and serve, in part, to clarify issues for the longer term.
- Near term deliverable are supposed to provide real near term benefits! These near term benefits might be delayed if a lot of time is spent trying to identify requirements and design solutions for a possible future that may never come.
The TenStep guest post provides some more depth on "building for today". But first, whether you are planning a project for the short term or long term, or using agile or more traditional methods, you will surely benefit in thinking through the project by using tried and proven templates. You will find a comprehensive set of templates to help you and your team shine - and your projects produce results - at
And now for the TenStep post, "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.
- 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.
- 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 sprint? The world is full of systems functionality that is written into programs but never utilized.
- 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.
- 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.