|
Agile teams use the retrospective to collect a set of start, stop, and continue actions at the end of each iteration. The point of this technique is to collect feedback as a team and focus it (through one of the above verbs) into actionable steps toward improvement. But retrospectives often produce a dozen or more actionable steps, and teams can grow nauseous from seeing the same things show up retrospective after retrospective with little or no progress made. So, how does a team break this cycle? By prioritizing only one or two activities as goals for the next iteration. It’s hard to remember to work on a dozen (or even half a dozen) things at once, even when you don’t have an iteration of work to complete at the same time. Remembering to focus on one or two goals is much easier, especially when your entire team is also thinking about those same goals. Finally, the team needs to close the loop by discussing the outcome of each goal in the next retrospective.
And there you have it: continuous improvement. Comments (1)
|
Show/hide comment form
| < Prev | Next > |
|---|
Agile Marketplace - Announcements and Special Offers
White Paper: Code Review IS an Agile Process!
Peer code review is one of the most effective ways to improve Software Quality – but is it Agile? Done correctly, it absolutely is. This white paper tells you how.
Download Today!
Virtual Conference: Collabnet Agile ALM
Stay current by attending CollabNet’s virtual conference, Agile ALM for Distributed Development, Thursday, April 15, from 7:30 am to 3:30 pm PDT. Free registration.
Register Today!
Webcast: Moving Build and Code Quality Upstream
This interactive panel discussion moderated by Bob Aiello, Editor-in-Chief fo the CM Journal brings industry experts Anders Wallgren, CTO of Electric Cloud and Gwyn Fisher, CTO of Klocwork together for a candid discussion of the cost savings, productivity and quality benefits that can be achieved by stabilizing builds and code quality as early in the development cycle as possible.
Register Now!
Collabnet -TeamForge 5.3
CollabNet TeamForge 5.3 includes Dynamic Planning—providing flexibility to model release scope and timeline in a single view. Now, you can easily manipulate/adjust release data.
Download Your Free Trial
Requirements-based testing (RBT) can help to ensure comprehensive test coverage, reducing the risk of failure and improving software quality. This white paper details how application lifecycle management can be used to more effectively implement RBT processes, offering greater collaboration, traceability and control.can help you increase efficiency, reduce project risk, and improve overall software quality. Learn how MKS Integrity for application lifecycle management enables RBT, delivering full lifecycle traceability to help ensure that project requirements have complete test planning and execution coverage.
Download the Requirements-Based Testing whitepaper
PureCM –SCM for Agile Teams
PureCM helps you to manage development in short iterations: keeping track of changes, supporting automated builds and preserving frequent snapshots of your projects.
Get the free trial now
I think the product backlog exists in multiple forms. You have the backlog that comes from the Product owner and testing, but also the product backlog from the experience of the team in the iteration. I think both are equally important and should be prioritised together for maximum benefit.
Regards,
David
http://www.jacksguides.com