All of the things that I suggest that we measure on software development teams, from these current seven blog posts as well as other things that I’ve written, are all about ways of improving the efficiency of our software development process. We measure to understand and improve.
Agile is all about getting and learning from feedback and there are several feedback systems in Agile that we can draw upon.
Perhaps the most obvious form of feedback is the feedback that we get from our customers and users as we’re building software through our iteration demos, as well as product releases. This is oftentimes where we learn the truth of our work and how it impacts
Sometimes, when we deliver the software that we’ve built to our users we find it isn’t what they were expecting. Language is a blunt instrument and describing a feature in English doesn’t give enough fidelity for developers to know exactly how the feature should be implemented and behave. As a result, it’s not uncommon to deliver a feature and have the customer say, “That’s not what I asked for. That’s not what I wanted.”
There are other feedback loops that are also important in Agile. Code reviews and iteration demos are an important way that the team gets feedback on what they’re building.
But perhaps the most important feedback that we get at the team level happens during the retrospectives. Retrospectives are a vitally important part of the Agile software development process and when we are able to get good feedback from our retrospectives that we can act on then the team can improve very quickly. It’s better to make minor improvements regularly then trying to make huge improvements that may not actually stick. Retrospectives are a way of helping the team identify what small improvements can be made and to check in and measure that progress.
Agile is all about feedback and getting feedback at many levels. For me as a developer, the most important feedback loop that I engage in is the red/green/refactor loop of test-driven development and my continuous integration server.
I run this loop constantly, many times every hour when I’m developing and so the efficiency of this loop is critically important for my own personal productivity as a developer. I can run a local built and execute all of the unit tests in typically just a few seconds. When my local build succeeds it is automatically promoted to my build server, which oftentimes can run in just a few minutes and tell me if there’s any conflict with the work that I’ve just done in the rest of the system.
This is the feedback that I find most valuable as a software developer engaged in Agile software development practices. The build is our eyes and our ears that allow us to pay attention to the health of our code and this is why I feel that the build is one of the most important feedback loops for Agile software development.
Frequent feedback is generally better than infrequent feedback. Clear feedback is generally better than vague feedback. Feedback that we can act on is far more valuable then feedback for problems that cannot be resolved. The quality and efficiency of our feedback loops are the critical factor in making our processes work efficiently.
Finding out about a defect immediately when I create it and being able to fix it in a matter of seconds rather than having it slip into production and become a major crisis is a huge value of these practices. Knowing that I always have a buildable system is also hugely valuable for letting me see the real progress that I make as I build a system.
Previous Post: « Measure Costs of Not Delivering Features
Next Post: Why Practice 3: Integrate Continuously »