Moving Agile development teams beyond "rejection" stories

Moving Agile development teams beyond "rejection" stories

How can we get development to be more detached from work so rejected stories are not taken personally?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

I'm not sure what you mean by "rejected stories." Is it a story that was demonstrated to the customers, who said it didn't deliver the functionality they expected? Or is it a story that was handed off to "test" in a waterfall fashion, and "rejected" by the testers?

Either way, it is a symptom that the development team is not using the whole team approach that is central to Agile development, and that the feedback loop is much too long. When we collaborate closely with customers from the beginning, get concrete examples from them of desired system behavior and turn those into tests that drive development, they won't have any unpleasant surprises during the iteration demo. When testers and programmers work together throughout the development of a user story, working together on the high level acceptance tests, testing and coding in tiny increments so that development stays on track, there won't be an antagonistic situation of a tester "rejecting" the delivered code. Hold frequent retrospectives – maybe even after a story is completed, just for that story – to bring the whole team together and identify the biggest impediments to successful delivery. Is testing falling behind coding? Perhaps the programmers can help with automating tests and other testing activities. Are the testers physically separate from the programmers? Move everyone so all roles of the development team sit together, or if that's not possible, use video and audio to facilitate real-time, face-to-face communication.

Changing from a phased-and-gated methodology to an Agile environment is a big cultural change. Testers, programmers and other team members need plenty of time, support and training to make this move. Managers should nurture a learning culture and make quality, not quantity or meeting deadlines, the goal. As Jurgen Appelo points out in his new book, Management 3.0, teams need to be empowered, so they can self-organize with a clear purpose and shared goal and grow appropriate structure. They need time and resources to develop competence, and team members need to be energized. Testers and programmers who never worked together before need time to experiment with the best ways to collaborate. It's not going to happen overnight, so get your team together and identify one baby step you can take today.

This was first published in November 2010

Back to top