Sunday, March 27, 2011

Technical Debt

It was everywhere. The team could not touch any part of the system without it having side effects elsewhere. Half the team velocity was spent cleaning up side effects. The code was in such bad shape. All unit testing done by the team's predecessor was manual.

The web apps' session data was over a Meg per user. Business logic was spread through multiple tiers. The app would support less than 50 concurrent users before crashing. It had to support 10's of thousands of users. So many bugs so little time.

As with agile teams, we made our technical debt visual. The team provided the news to our product owner. It was serious. The message was, "It would do very little good to add features given that the app would not scale". However, our business partner was on the hook to show new functionality to the key users for the pilot. What to do.

After much hand wringing a decision was reached. The team would finish with the targeted features for the pilot. Given that there we're only a 20 users, performance would not be an issue. The business in turn agreed to allow the team to play the performance technical debt cards after the new features were completed. After all, it would take 30 days to play the performance technical cards. Without the performance fixes the application would never deploy to all the users. Prioritization worked. Technical debt was explained in terms of business impact. The business in turn made a priority call. It was text book.

The partnerships was growing stronger.

- Posted using BlogPress from my iPad

No comments:

Post a Comment