Tuesday, July 14, 2009

Quality in the scrum process

Ever wonder why your last sprint tanked? Was it because of changing requirements, undiscovered work that was found during the sprint, or perhaps because your team finished on time but the quality was too poor to release. Let's hope that the retrospective brings these issues to light and your team has the courage to make positive changes.

On the last note, of poor quality, this happens to teams more often that I'd like to think. Since software development at some level is a serial process you can find that we put our test and quality assurance team members in a tough spot... Hurry up and test the product now that we're done coding.

Has this ever happened to your team? During sprint planning your team picks the right stories, they diligently task them out and the team gets started. Of course being the excellent QA engineers they are, they do all the test case creation and automation they can before they see the features coded for the first time. Giving QA a code drop before it's final helps them finish their test cases and gets them started on setting up automation runs but it eventually comes down to having the first finished build they can test the features with.

The software developers do the coding and unit testing before handing it off to QA. Now here's the rub. Often the developers end up using nearly all of the available time in the sprint to finish their features, leaving precious little time for testing. I'd like to say that my teams have never run into this but that's not true. Even after talking about it at retrospectives this is an area where we continued to be challenged. Eventually we did something non-scrumy, we created a deadline for features to be finished by so that the team could complete all of the required testing. While the agile purists out there are surely grimacing this worked great. It allowed the developers to have a firm deadline for hand offs to QA and allowed QA enough time to finish all of the functional testing, regression testing, performance testing and final pass system testing. Now some might say that the developers should have done the testing too which we did but do you really want the person who wrote the code to do the testing too? I don't think so. We had developers test other developers code and over time we were able to reduce the amount of time it took to test everything. In the end we were successful but it required some different thinking.

No comments:

Post a Comment