Scrum + Hip Hop: Vol. 7
Don’t Forget the Soundcheck
An often overlooked, and misunderstood part of Agile is testing.
In waterfall, software developers write code, and throw it over the wall to someone with the title of Quality Assurance Analyst (or something along those lines). While they’re testing, the developer moves on to the next thing they need to code. If (more like, when) the tester fails the code, and sends it back over the wall, the developer throws their hands in the air (waving ’em like they just don’t care), because, to channel Missy Elliott, they’ve gotta “…put their code down, flip it, and reverse it.”
Teams who are new to Scrum, and are weening themselves from waterfall, have a tendency to cram this assembly line into two-week cycles. They heard somewhere that sprints ares supposed to be that short, and figure that’s how it’s done.
“Hit you with no delaying, so what you sayin’ yo?” — Busta Rhymes
As you’d expect, testers get overloaded toward the end of the each sprint. Every. Single. Time. It’s about here when folks start talking about adding “QA sprints” to “level set” (a term which makes me cringe) the crazy amount of work that’s bombarding testers.
“Microphone check” is a common phrase in Hip Hop that means you’re about get some some knowledge dropped on you. Applying the idea to the Agile world, think of it more like a soundcheck. Before any Hip Hop crew takes the stage, a professional sound engineer tests out every microphone; where it’s placed on the stage, the quality of sound it produces, and its balance in relation to the other mics in the mix. You wouldn’t want your emcees mics to get drowned out by the DJ’s 1s and 2s, would you?
A soundcheck is like QA for music so bands don’t sound like garbage on stage. Not only does the sound engineer test audio quality, he or she relies on feedback from performers to adjust audio levels on the fly. Doesn’t that kind of sound like Agile, and reacting to change?
“Whateva’ she said, then I’m that. If this here rocks to y’all, then react.” — Eric Sermon
Like I said in Scrum + Hip Hop: Vol. 6, the word “developer” is often thought of as people who code; software developers. But like sound engineers ensure great-sounding performances, testers ensure great, working software. In Scrum, they need to be considered developers too. A development team can be made up of coders, UX, designers, and testers. Finished software means it’s been tested, right? It all goes back to the definition of done. If you’re showing off functionality in a Sprint Review, and it doesn’t work properly because the code is borked, is it really done?
When Jay-Z hits the stage, you can be sure his sound engineers have already performed extensive, and thorough sound checks ahead of time. If they hadn’t, would you be satisfied after paying $350 for front-row tickets?
So how do you think customers will react if code hasn’t been thoroughly tested before it’s rolled out? If testers continually require QA sprints because they’re overloaded, pushing back the release date… again… how likely are they to be feel like they’re being taken for granted?
Including QA in Scrum ensures that everything is working smoothly, and user stories are actually done timely. Without it, it’s like someone in the front row who only hears the backup singers when Beyoncé makes a surprise guest appearance.
The Next Track: Don’t Forget the Lyrics
