The waterfall software development process literally ran on product requirements because they were the foundation of everything that followed the project’s inception. The requirements were supposed to be sufficiently detailed that engineering development could write code module specs on a one-to-one basis with product feature descriptions. The marketing group was supposed to see a finished result for which their initial requirements document could be a product brochure or even a user’s manual.
The flow of the waterfall SDLC took marketing requirements to software architecture, to module design, to integration, to product verification in a series of orderly processes. The results of each process referred back to those initial requirements so that the finished result was exactly what those requirements predicted. Or at least that was how it was supposed to work.
Too often, verification pointed up problems that were caused directly by disagreements between engineering and marketing over what the requirements actually specified. Increasingly, requirements had to change in mid-stream in order to reflect new market realities. Extensive re-work to correct the resulting problems and oversights caused long release delays. And ultimately, the product release process stretched months beyond its intended schedule causing marketing windows to be missed.
The Agile methodology was introduced to cure all this.
The Agile Development Methodology
Agile runs on the idea that, once the initial system development is done, features are added to an existing structure and bugs are fixed as their priority rises to place them into the current sprint cycle. The sprints are short one to two week development/release cycles that add a few features and fix a few bugs. Each of these cycles releases working code that places these limited changes directly into production. But what of the product requirements?
The requirements are what the system was, is, and will be expected to be. A vital participant in the Agile method is the product owner, the direct representative of the marketing team who designed the product system in the first place. The ‘production’ member of the team is the person charged with keeping an eye on the intended functionality of the product and making sure that the Agile sprint efforts don’t wander away from it.
By its very definition, Agile is intended to make the feature/bug fix effort much more responsive to changing requirements. The production representative manages this process to keep it moving toward a product that works and supports all that marketing intends. This requires production to be constantly on top of making sure the requirements are being used as the map for the sprint’s activities and that they are updated as necessary to reflect feature changes.
To accomplish this, production has to work with QA on an approach that is based on the idea of testing the features/bug fixes to the intention of this managed set of requirements. This is what allows a synergy between QA and development that moves toward finding the best working solution for each problem. While this will usually follow the original design intention, on occasion, it might not. Production has to stay on top of making sure that the requirements specifications are continuously updated to reflect the current market intentions for the product and continuously used as the reference for the sprint’s task planning.
One of the main attractions of Agile development is to spur creativity in both design and development and QA’s perspective has a lot to contribute to this process. The sprint planning session is an excellent place to have developers and QA look at each feature/bug fix story to see what its optimum resolution is rather than taking its content as a commandment on what needs to be done. When they both work together with production, Agile can live up to its own intention of being a fast, flexible methodology. It can keep development on the desired track as reflected in the requirements while supporting marketing in taking advantage of the most current industry trends.
QualityLogic stands ready to work within your Agile development process. Our engineers know the Agile operational concepts that produce quick, short-term turnaround of proposed features into working code. And all without disrupting long-term system stability.