By Paul Cooper, Senior Performance Test Engineer
A fundamental expectation for a high performing Agile team is to have clear requirements to begin building the product(s) with sprints and validating demos. The Agile approach supports the philosophy and the reality as long as the integrity of the requirements remain clear and well thought through. What happens when requirements run amok?
Two leading principals of Agile are:
1) Satisfying the customer through early and continuous development.
2) Welcome changing requirements, even late in development.
These are nice goals that work well when the customer understands and can reliably express their product vision to the development team. The development team divides the work into manageable chunks (sprints) and produces deliverable demos. The customer evaluates the demos and requests changes if needed and those changes are worked into future sprints. Well that’s the way it is supposed to work. Sometimes situations occur that break that iterative process.
One such item is when the product vision is not as well understood by the customer as they believe it is. As a result, over time, a widening circle of new requirements pop up. Those new requirements may detrimentally affect or be incompatible with the existing design decisions and code base.
In a separate issue the customer may want “special one off” efforts to handle immediate needs, such as a demo of a new feature for a potential investor. The new feature is required on short notice and supplants the current sprint’s work in progress.
In yet another situation, after successful demos, the product is partially deployed and now requires maintenance and support for users in the field. Users are finding unanticipated usability issues, requiring immediate fixes to prevent erroneous input from being propagated into wide use by the database. This support work will draw away resources from the current sprint or may require abandoning it altogether.
Each of these cases can create pressures to modify or drop work in progress. Common examples can include times when alternative goals are introduced, new features need to be integrated, or maybe a related yet separate effort is required to be developed in parallel. In the ideal case the development team should be able to push back against these pressures to ensure the integrity of the existing design/codebase as long as it is still valid.
The development team however may not be afforded the opportunity to push back. The customer may be affected by personnel, management or political changes which require changes to the course of the project. In the worst case these changes may be uncertain and cause vacillations in both short/long term goals with shifting priorities. The development team wants to be responsive to the customer’s needs but the push and pull of changing priorities and/or directions will likely cause short term fixes that work against long term best practices. The customer may have expectations that the supplanted work is still in progress even though that sprint was abandoned to take on the new goal.
At the time of these events it is clear why the decisions are being made, but later on the rationale for those decisions can become vague or lost. Both the customer and the development team may have significant changes in personnel so that legacy knowledge is lost. At a later date the customer discovers that an expected feature is not present and it is unclear why it is absent. Now there is technical debt due to the missing feature plus there is no readily available record as to why or how that debt came about.
To aid the development team in answering such questions and to aid the project’s post mortem, a record should be kept that logs changes to design/implementation or even personnel during the project. A good time to log those changes is during each sprint retrospective. A short discussion covering any events that positively or adversely affected the sprint and the expected repercussions of those changes should be included. This discussion may also be a helpful guide in the planning for the next sprint.
Technical Debt is common to most projects, but in projects with insufficient specification, poorly understood goals and shifting priorities, it is just as important to recognize sources of the debt as much as the debt itself. By recognizing the sources, it may be possible to raise warnings and implement remedial actions earlier in the process, thereby increasing the chances for a successful outcome.