A common term used in development businesses that’s focused on preventing problems is “assurance”. We often see businesses apply “assurance” to plans, designs and other activities – but crucially not against working software. This kind of practice, reminiscent of the process police checking that the artifacts are all there, doesn’t tend to positively affect quality.
Spending a small amount of time checking plans, roadmaps and architectural approaches is a good idea but spending considerable time or effort is actually counter-productive. We learn far more from working software that we can test, try out and otherwise play with than we ever learn from studying the plans. We’ve seen many projects where the process assurance people checked all of the processes were being followed and yet the resulting product was bad. We’ve also seen many examples of the opposite: teams that didn’t follow “the process” but succeeded in making high quality products their customers loved.
The lesson we learn from this is that working software really is the only meaningful measure of progress, and the only meaningful thing we can test. Software development, other than specific edge cases such as model driven development, simply isn’t transformational. We don’t just take the requirements and translate them into design, then into code. We learn and evolve as we’re going along.
Avoid spending time and money on “assurance” of plans, designs and other intermediary artifacts. This activity slows you down in terms of building the product, the thing you actually can assure. We recommend putting the emphasis on the output of activity, not the plans and designs. Regular customer/user demos, automated and exploratory testing are all valuable activities.