Agile2013

Teams transitioning to Agile usually suffer from issues due to large inherited technical debt. In our example, we have faced problems like moving towards shorter iterations with shorter time for regression testing, trying to cover poor code with automated tests, prioritizing which refactorings to apply on which code, and convincing managers with the value of refactoring.

To tackle these challenges, we have crafted a roadmap of three stages: (1) Quick-wins; simple and least risky enhancements (2) Divide-and-conquer the code into functional, utility, and architectural components, with identified and clear component interfaces. (3) Build quality in the code by wrapping components with automated tests. The intent was not to refactor, but to qualify the code to be refactor-able!

In this session, I will present the challenges that we met while applying this model on two products (300 kloc and 1 million loc). I will explain which steps worked well and which did not, and when it was necessary to step over some of them and why. I will explain how we tried to answer the famous question by managers: *When are we going to finish?*, I will explain some visual indicators used to relate the effort spent with the value achieved. I will also present some insights about refactoring anti-patterns that we found out to be the real impediments of refactoring. Finally, I will present interesting facts about how managers are involved in such technical effort, and how developers sustained such a lengthy and hectic roadmap of refactorings.