This post is a write up to my talk titled "How can Agile help you in clearing the technical debt?" presented at the Scrum Bangalore Meetup 2013. It was a short talk for 30 Minutes, So thought of a write up to elaborate the ideas on the slides.
Defining Technical Debt
As per Wikipedia, "Technical debt metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a code base". Technical debt is most understood when it is compared with Cost of Change of software. More Debt means the cost of introducing a change in your system is more.
The term Technical Debt was coined by Ward Cunningham in the year 1992. He used the term to explain to his manager about a particular refactoring which he wanted to do. Since he was working in the financial industry it was easy to communicate in terms of debt. Ward explains more about the metaphor here. The term is immensely popular in communication of the importance of code refactoring to the business and stake holders. Like financial debt technical debt is some times unavoidable but we should take steps to minimize it.
As you can see in the above image when you have technical debt in your system you could either pay the interest or pay back the principle. When we do regular stories we do bit of "extra" work than what ideally needed due to the technical debt. This is an example of the interest payment. It is important that we take some time and effort to pay back the principle by refactoring and cleaning up of the code.
Technical Debt in Agile Context
The below principle from the list of agile principles was the best one I could find which refers to clearing technical debt "Continuous attention to technical excellence and good design enhances agility". In agile projects working software has a lot of emphasis but this in no way implies that the intrinsic value of software can be compromised. As we push for more and more features it is important that we take time to look back at the health of the application. So, make make sure that your agile projects do not become Fragile as it grows.
There are lots of ways to deal with technical debt. I want to talk about 3 simple steps that we have tried in our projects.
1. Tools - Your must have defense
One of the major improvement with the agile development practices is the widespread usage of continuous integration (CI). Your CI environment should be configured to measure the health of the application. It should include the report from static code analysis and test coverage applications. SonarQube is a god platform where you can create a dashboard and see results from the tools mentioned above. It also has a plugin to view the technical debt. Apart from the tools you should be using good programming practices and guidelines.
2. Negotiating with Product Owner
The second techniques that we have tried to minimize technical debt is to negotiate with the product owner and take him on board in the technical improvements that we wanted to do. You have to Use the opportunity of Change requests to clean up the functionality. We had a module in our application with lots of bugs. There was a major change request which was planned on that module. After much discussions we identified that it would be much easier to rebuild the module than fixing the issues. Once we rebuild the change request was 75% easier to implement compared to the old code.
This means that we have to evaluate the possibility of refactoring with every opportunity and go for it when the time is right. It is the professional responsibility of a developer to communicate dept of technical debt in the application and we should take all steps possible to minimize it.
We can also have technical Stories in Release planning. Contrary to a user story, a senior developer should describe the success criteria of the story. This is another case where you need to get your product owner on board.
3. Trying out new Stuff
In our projects most things can be done multiple ways and we have to choose one of them. There are also situations where we are not sure about the complexity of the task performed and story point estimation is difficult. We can use spike to deal with such situations. A spike is an experiment that allows developers to learn just enough about something unknown in a user story, e.g. a new technology, to be able to estimate that user story. A spike must be time-boxed. This defines the maximum time that will be spent learning and fixes the estimate for the spike.
A daemon thread is a low priority thread that is running on the operating systems. We have used the same strategy to do a major change in our application. It was upgrading our frameworks (Spring, Hibernate and Tapestry) to their latest versions. Since it is a time consuming activity, we do not want to stop everything else and work on it. So, we choose to keep doing it as a low priority tasks and it took us 10 sprints to complete. Since the team continuously delivered features during this period it was very easy to get the buy in from product owner.
Useful Links:-
4. Using Spikes
Note:- There are many ways to define and minimize technical debt. I have discussed few ways that we have successfully tried. You can go through the above links to find more information and choose the best methods that suits you.
No comments:
Post a Comment