Jeremy discusses his experience working in development teams that are too framework-centric in their iterative planning. Sometimes the outcome is a framework that stagnates the development process, impedes the introduction of new features, and causes team members to look for ways to outsmart or work around the framework in order to meet business needs.
A good iterative plan that strikes a blance between Risk-Driven Development and Client-Driven Development can help with such problems.
Iterative Planning
Unless I plan iteration development cycles, my development cycles are typically unbalanced, either incorporating too much architectural core development ( mainly aligned with Risk-Driven Development ) or too many features important to the client ( Client-Driven Development ). The key to less sleepless nights and more confidence as to the success of a project revolves around striking a balance between these two different and competing approaches to development.
Risk-Driven Development
Risk-Driven Development is about 1) identifying those high risk specifications that need to met by the project and 2) working on those items early to assure that they can be accomplished by the project. Often these risks are associated with the architecture core and drive the selection of key technologies and solutions.
The desire is to flush these issues out early before you spend a considerable amount of time going down a path to realize the architecture won't meet your high-risk needs and a complete rewrite is necessary.
Client-Driven Development
Client-Driven Development is about 1) identifying those features most important to the customer and business and 2) completing those items early so the client sees progress and can provide feedback on those features early and on-going. Unless a customer sees progress and feels empowered during the development process, one may not have a project.
The desire is to keep the customer happy and engaged in the project by delivering those features that are important to the client and their business.
Iterative Analysis and Design
I have convinced myself that a successful project involves iterations that strike a balance between those high-risk features crucial to the architecture core and those features crucial to the client. This is in addition to each iteration should result in an executable but incomplete system containing production grade code.
Craig Larman in his most excellent book, Applying UML and Patterns, discusses iterative design in awesome detail and the importance of striking a balance between those features crucial to the architecture and to the client. Often you want to pick items to accomplish in your iterations that are a blending of 3 qualities:
- Architecturally Significant - Items that force us to design, test, and build the core architecture early.
- High Business Value - Items that are really important to the business so that the client can see progress and provided feedback early and on-going.
- High Risk - Items that may be risky to accomplish, such as the "system must be able to handle 500 concurrent transactions."
A good blending of the above should hopefully keep your projects balanced and avoid the iteration pendulum from swinging too far to the architecture core or client.
This combined with the fact that each iteration should result in production quality, executable code will keep you from spending too much time on framework development that results in nothing to deliver.
Conclusion
Planning your iterations so that they combine a healthy combination of Client-Driven Development and Risk-Driven Development items that are architecturally significant, have high business value, and are high risk should keep a project from being too focused on the architecture or on the needs of the client.
If each iteration also results in a partially-written solution that can be executed and contains production quality code, you can also assure yourself working code early in the project and throughout its evolution.
Related Articles
Drinking: Gyokuro Green Tea