1) Agile teams need to govern their process – What are your rules, when do you bend them, and when do you call out an issue? Are developers going to accept poorly defined stories and permit changes in scope during a sprint? Will testers speak up when stories are more complex than the development exercise and should be sized accordingly? Are blocks formally documented and resolved quickly, or do they linger? Agile teams achieve higher levels of productivity, quality, and job satisfaction when they talk openly about places where improvements are needed.
2) On the same page – I’ve written before on how important it is for teams to have a shared understanding of their goals and requirements. One really important step is to insure agile stories have pass/fail acceptance criteria. “The email form should make it easy for users to enter multiple email addresses” could easily be rewritten as “The email form should allow entering up to ten email addresses” which clearly provides a business rule and some guidance on the user interface.
3) Self Organizing = Data Driven teams – Once teams have settled on their agile practice, it is important to discuss and select some metrics to track and use to drive improvements. Are your performance metrics stable with every release? What percentage of your test cases are automated? How many defects were created? When discussing potential issues, teams perform better when metrics are developed and used to drive improvements.
Leave a Reply