Agile != Ignoring Requirements
Below is a note I recently placed on an architectural context diagram.
"The initial release of the XYZ Application does not take any workflow or application integration into consideration. This was at the request of our client ABC. This context diagram shows the XYZ Application as delivered, without the proper integration and workflow built into it.
Future enhancements will need to build the workflow and the integration into the architecture. Because the client has requested we ignore these aspects of the application architecture upfront, it will be a greater effort and take more time to accomplish than if we would have been allowed to account for them upfront.
It is a misconception to think of this as an agile approach. An agile approach would take into consideration all known requirements and plan releases accordingly. The client requested we ignore the requirements believing this would save time because they believe that is what agile methodologies do. In the long run this approach will greatly increase the complexity of future releases, and therefore increase the effort and time required to deliver them."
Although it is wrong to add features, or plan for features, that 'may' be added in the future, it should be an absolute must to account for all known requirements. They may not all be built into the first few releases, but the first releases are built taking them into account. I have run into this several times now. Someone hears the term agile, they look into it enough to become dangerous, and then start applying it in the above fashion.
They want a first partial release, and they want no thought put into the following releases. Agile development does not ignore known requirements. It does allow for new requirements that were not know at the start of a project and changing requirements, but it absolutely does not call for the ignoring of know requirements.
This particular project will end up costing the client twice the money it would have cost if they would not be demanding that we ignore known requirements.
"The initial release of the XYZ Application does not take any workflow or application integration into consideration. This was at the request of our client ABC. This context diagram shows the XYZ Application as delivered, without the proper integration and workflow built into it.
Future enhancements will need to build the workflow and the integration into the architecture. Because the client has requested we ignore these aspects of the application architecture upfront, it will be a greater effort and take more time to accomplish than if we would have been allowed to account for them upfront.
It is a misconception to think of this as an agile approach. An agile approach would take into consideration all known requirements and plan releases accordingly. The client requested we ignore the requirements believing this would save time because they believe that is what agile methodologies do. In the long run this approach will greatly increase the complexity of future releases, and therefore increase the effort and time required to deliver them."
Although it is wrong to add features, or plan for features, that 'may' be added in the future, it should be an absolute must to account for all known requirements. They may not all be built into the first few releases, but the first releases are built taking them into account. I have run into this several times now. Someone hears the term agile, they look into it enough to become dangerous, and then start applying it in the above fashion.
They want a first partial release, and they want no thought put into the following releases. Agile development does not ignore known requirements. It does allow for new requirements that were not know at the start of a project and changing requirements, but it absolutely does not call for the ignoring of know requirements.
This particular project will end up costing the client twice the money it would have cost if they would not be demanding that we ignore known requirements.
posted by tadanderson at 6:48 AM
0 Comments:
Post a Comment
<< Home