I found the blog of Bredex, a small company in the north of Germany I have worked 10 years before. They started to blog last year and have quite some nice posts on it. One post diskusses whether feature driven development is a double edged sword. Alex wrote that they experienced in a project that focusing on feature delivery is causing problems in the software quality. Refactorings that must be done to keep the software maintainable will not be done, because the team wants to deliver features. Yes – that is the main goal of agile software development – deliver a high business value quickly.
Recent financial crises must teach us another aspect. We can live a high quality live on the cost of the future. Some like to overspend and increase their debt. The same you can find in software projects. If you try to deliver as much features as you can, you will increase your technical debt. Even without much pressure from as business department a team can be overcommitted and will deliver features on the cost of quality. The bad quality can be visible to the customer, due to too many defects in the delivery, or it can be unvisible due to an awkward design. The last one is technical debt.The first one – high defect rates are usually tackled with proper conventional quality assurance. The technical debt can be tackled with contiuous refactoring.
But how can you measure your technical debt? By automated tools that output software quality metrics. One of these tools is dependometer – Valtech’s open source solution. Another very good tool is Sonar from codehaus.
If you are planning a sprint and you have delivered 15 story point and your technical debt is not increasing, then you are running on a reasonable velocity. But if the quality metrics show you an increase of the technical debt, then you are too fast and you should put less story points into your next sprint and plan tasks to refactor or clean up the code.
Some questions pop into my mind now: How do I explain this to the customer? If I report the velocity, they will see a drop of it. So better not to report the velocity? Or start with a low pace assuming that you can get faster in later sprints? Maybe we can report the quality metrics too – defect rates and technical debt. It really depends on our customer’s nature.