September marks the Agile Austin annual retrospective. This year we decided to use Innovation Games(r) to make the session more interactive and engaging. We’re glad we did.

The responsibility of facilitating the retrospective goes to the Program Chair of Agile Austin, that would be John Heintz. This year John decided not to repeat last years retrospective: although it was very worthwhile, it consisted mostly John doing all the talking and writing (then running out of time ;).

John asked Austin’s own Jeff Brantley, and trained Innovation Games facilitator, to help and run the retrospective as an Innovation Games activity. Both Innovation Games and inviting Jeff turned out to be a great ideas, and nearly everyone got engaged.

The planning for these games was mostly simple, the Speed Boat and Prune the Product Tree games were clearly the best choices to play. The single challenge was time: the whole activity needed to fit into 90 minutes – making it impossible to first play Speed Boat, then Prune the Product Tree. While Luke Hohmann (the creator! of Innovation Games) was in town as a Distinguished Agile Austin Speaker, Luke suggested that teams could simply play different games. This would give the community some results from both games.

Jeff and John, inspired, decided to go even further: half-way through, teams would switch and finish the others’ game.

In practice this idea worked pretty well. The total group was split into two teams with Jeff facilitating the Speed Boat game and John facilitating the Product Tree. After both teams had slowed down the facilitators swapped the teams (but the games and facilitators stayed in place.) Each team was introduced to the new game and briefed on the stickies placed so far. This had a clear benefit that each team got to absorb what the other was working towards. The amount of new activity was minimal, but some new stickies were added and existing ones newly organized.

Given significant time constraints this technique seemed useful, but it wouldn’t be first choice.

We’ll be presenting on Toxic Code. This is a topic that I spent a lot of time on last year, working with a client to re-architect a system from the inside out while it was running in production.

Here’s the abstract of the session:

Technical debt had originally been conceived as an expediency measure – “a little debt speeds development so long as it is paid back promptly with a rewrite.” However, like financial debt, unrestrained borrowing can lead to a broad spectrum of difficulties, from collapsed roadmaps to inability to respond to customer problems in a timely manner, and anything in between.

Recent advances in source code analysis enable us to quantify technical debt and express it in $$ terms. By so doing, the software development process can be governed with unprecedented effectiveness. It is possible to constrain the “development on margin” mal-practice and avoid the toxic code phenomenon: technical-debt-to-value ratio of 100%. Moreover, even toxic code can ultimately be “marked-to-market” by reducing/eliminating technical debt.

The combination of Agile refactoring practices with technical debt analytics brings rigor to the software development process through:

Providing quantifiable data about the overall state of the code and its value

Driving the refactoring carried out through the Agile process from a risk mitigation perspective

Balancing the technical debt work stream vis-a-vis other work streams

In the course of managing software development in this manner, your team will improve its design, coding, testing and project management skills. Ultimately, these improvements are the best antidote against accrual of technical debt in the future.