Tonight Scrum Master Trainer Rod Clarr presented at the Lincoln .Net User Group on Scrum and High Quality Code. The main point he made was that agility and high-quality code need to go hand-in-hand; developers need to produce the highest quality code they can.
Rod walked us through how to measure quality from different angles. From a functional standpoint – does the product perform as expected – quality is easy to test if you have done a good job defining what the product should do. From a structural stand point, it may not be obvious how to determine what quality code is, but poor quality code does rot faster, especially when it does not have unit tests.
Rod described two concepts to help qualitatively evaluate the quality of code from a structural standpoint:
- Viscosity – how hard is it to move the project in a different direction by adding or changing a feature. The more viscous, the more rigid, the worse the structural quality is.
- Testability – how difficult is it to write automated tests for the product – the more difficult, or the less coverage you can achieve, the worse the structural quality is. A project needs to have good quality before it gets to QA-style testing; by that point it is likely too late to improve structural quality.
Rod also talked about the sweet spot of the intersection between Scrum, Acceptance Test-Driven Design, and Component-based Architecture. Scrum is the process to manage risk in the process, ATTD is the top-down approach to defining what done is, and Architecture is the bottom-up test-driven development that results in good OO-based design.
Most of what Rod talked about resonated with my experiences. We’re currently focused on moving a number of iterations worth of work to production so that users can validate the progress we’ve made – the longer we wait to get to production, the more risk we incur in assumptions that we may have made that won’t be revealed to be wrong until users really pound on the code.
We also need to include more technical debt stories as we go; which Rod talked about as being important, or at least, not adding more technical debt knowingly. Our team has discussed adding two technical debt iterations per year, but I wonder if a better approach might be to allocate a number of story points per iteration to beat back technical debt.
Rod talked about getting the whole organization on board with the importance of quality and the Scrum process. Keil commented about this after the meeting, and I totally agree, that it is a very different thing for management to be OK with a project being run in an agile process versus management running their own process in an agile way (the latter being the much less risky option of the two).
Finally, Rod talked about the importance of feed back loops in requirements gathering. The first thing you need to do is confirm you understand what the customer is asking for, and then ask questions. We have started doing a better job of this on our team by creating good meeting notes to record decisions made (which have proven very valuable to refer back to), and by adding conditions of acceptance to all of our user stories to help us define and agree on what done is.