Friday, August 28, 2009

Agile and Scrum buts causing Technical Debt

I am sure you must have heard some of these Agile and scrum buts which contribute to Technical debt?
  • Re-factoring: I am aware that particular section of code needs re-factoring, as it was just built as a prototype. But it will have to wait, as the feature development takes priority over re-factoring.
  • 3rd Party dependency: I know we should integrate with these newly released 3rd party libraries as it contains the fixes we need. But based on prior experiences it could take up to a week. It would be better if we do it in the next iteration.
  • Tests: I wanted to write end to end automated test case for this feature, but if I develop that, I can’t test the other features under development. I will plan for automated tests in next iteration.
  • Defects: We are done with our stories, but we have 10 open defects that we plan to target first thing in next iteration.

The above “buts” will reduce the team’s velocity and add to technical debt. It will hinder teams ability to self organize and move them from being truly agile. If above reasons are ignored, for the first few iterations the teams might show good results and get away by breaking scrum principles. However in the long run this is a lose-lose proposal. Development of new features will take longer as development has cut corners for re-factoring effort. Development team will also spend considerable amount of time fixing defects that were missed due to lack of unit tests.  Test team will spend more time running regression tests and verifying defects rather than doing exploratory testing and testing new features. The further the team pushes integration with 3rd party library, the more risk it adds to the overall release due to last minute surprises.

Conquering technical debt in a timely manner is extremely important for scrum teams to be truly agile. There are some solutions that I can think of – Ignore it and pay the penalty everyday, take a break from developing new features and clean up the mess by adding additional people resources, re-design and start again…

Implementing agile takes a lot of discipline and buy-in from the management team, as it’s a big shift in how business in conducted. A disciplined set of agile and scrum best practices should be followed, such that it empowers teams to take right steps to deliver “world class” quality software.

1 comments:

Clem said...

Hi,

I completely agree with you on the fact that these nuts must be taken in account.
I know technically how to manage it, but I was wondering about how it could be managed through agile planning, that value only user stories points, which cannot be technical fix (for defects lot of people consider user story).
The biggest problem to me would be that velocity is impacted, but never at the same level on each iteration, so velocity is always going up and down...
I search for a planning practice that would take care of this. Have you any idea?

Clément (clem-it.blogspot.com)

Post a Comment