SearchSoftwareQuality.com just published the third in a short series of podcasts on software testing, this one on using Agile-Testing to speed up software delivery. The interview is a discussion between Yvette Francino and myself. It's about ten minutes, and you can
listen to it right now.
Toward the very end of the podcast, I suggest doing "Agile Adoption" starting with Technical Practices, specifically testing. This is different than most companies I've worked with, that general start out with implementing the management practices first.
I find that implementing just these practices - shipping every two weeks, daily stand-ups, assembling requirements just-in-time for each iteration - tends to create a certain set of risks. That's no surprise, and it's okay; the creators of extreme programming claim the practices
fit together and lean against each other. If we implement just the practices that are easy to do, and morph them to fit our agenda, we shouldn't be surprised when we
get tripped up.
On the other side of the coin you have those hard-to-start technical practices. I call them 'safety net' practices. They provide you with a regression test suite and shrink your test cycle time so you can hit that two-week iteration. They provide you with an extra pair of eyes through pairing or encourage discussion of what-it-is we are going to build and how-we'll-know we are done by story review and kickoff.
So I stand by my suggestion to start an Agile transition with technical practices. What's more, if you are a technical person, for the most part, you can just do them. Automating some parts of your work, having discussions with developers and feature-owners before coding begins, testing on a staging environment, or getting developers to pair or do TDD are all within the reach of the motivated do-er without any kind of stamp of approval.
But here's the thing. Toward the end of the podcast, I made a claim - that if a company adopted agile-testing practices, and the stopped, that they would be in better shape. In other words, that agile-test in isolation looks a lot like good testing, and, unlike some of the project management pieces of agile, that agile-testing can stand alone.
Yes, I realize that if you look hard enough, you might find government or military projects, maybe avionics projects or embedded projects, where you could argue that is not the case. I won't disagree. In this case, I am talking solely about the majority of commercial software projects working in a free-market, not regulated or slightly-regulated environment.
Even so, after I got off the phone, I paused. Using Agile as slang for 'good' is something I'm not in favor of;
you might even say it's dangerous. Yet, for the most part, I stand behind my statement; I really believe in it.
But that's just my opinion. What do
you think?