As I write this entry, I’m in the air above Boston, just about to land for the Software Test and Performance Conference. The trip is actually a twofer; I’ll be at the conference tomorrow, but tonight I’ll be out at the Boston SPIN (Software Process Improvement Network), a local user group.
… time passes …
After touchdown at Logan International Airport (Boston), there is no airport shuttle to the conference. Believe it or not, one of the editors at SearchSoftwareQuality.com works and lives in town. Not only is he going to the conference, but he also offered to pick me up at the airport.
And, true to his word, there he is. Also, true to his word, his modified black T-Bird is the loudest car in the parking lot. I suppose I can’t complain about a favor from a friend. And the FireBird has some serious horse power.
After I check in at the hotel, it’s time for The SPIN meeting on “Agile Software Development: Does it make a difference?”
Nearly as importantly, there will be pizza.
The Boston SPIN
Yes, there was pizza. So much pizza, in fact, that I missed a little meeting in the corner: a roundtable discussion of Reliability Metrics. Instead, I sit through an informal discussion with a few people who choose to sit at our table; deep enough that Dan Mondello does his own blog post on it.
I do get to see the main event, which was an introduction to Agile Software Development by Damon Poole. Damon is also the author of Do it Yourself Agile, which is nice – and free – e-book on the concept.
The slides from Damon’s talk are online. You can view them here.
A few of the ideas in the talk caught my ear enough to want to share here, in my words:
* We tend to like to think of our work as “done” when we have written code, or run tests, or completed requirements documents. The only “done” that matters is running tested features.
* Development with Legacy Software is just hard to do in general. Yet if you take it a piece at a time and slowly begin to apply agile techniques, over time, the software will become more malleable.
* There is no business value in a complex architecture. Instead of designing for extensibility, just build what the customer asks for and design a system that can be easily changed in the future. (Matt Heusser adds: In my entire career, every time we designed the software to be extensible in a specific direction, that darn customer asked to have it extended in a direction we hadn’t anticipated, and we had to start over at square one.)
* Agile development enables the team to change priorities every iteration. In this age where a new product like the iPod can radically change the business landscape in a matter of months, it might be better to not be locked into a requirements document with a multi-year release plan. Just a thought.
The big reveal
At the end, Damon didn’t see a business case for ‘Agile’ development. Instead, he layed out 14 different practices – such as continuous integration, daily standups, refactoring, user stories, and one piece flow. According to Damon, each of these practices can stand on their own, with perhaps a 5% performance improvement. Because the practices build on each other, doing several of them have a compound-interest effect.
I don’t think Damon meant us to take this literally or scientifically, but merely metaphorically, as a thought experiment. If every Agile practice stands on it’s own, and the lot of them, taken together, provide even more benefit – then why not try an Agile approach?