Your team has struggled for the past couple sprints with production deployments having not gone smoothly. Defects are being reported and perhaps some complaints are creeping in around a poor customer experience. Throw in a couple rollbacks or hot-fixes and a trend is clearly starting to emerge. Developing software is not easy…throw in a complex architecture and a few legacy systems and it becomes even more challenging.
The art and craftsmanship of software design and development is typically outside of the realm of the Scrum Master role so what can they do to influence and focus the team back on quality and technical excellence. Here are five thoughts:
Work with the team to establish a robust “definition of done”. One approach would be to use principles from The Checklist Manifesto with the Product Owner holding off on accepting a story until the checklist has been finished. Acceptance criteria is an important component of the definition of done. How does the acceptance criteria look and does the team fully understand them before making their sprint commitments? Make sure they are thorough, clear, and not being glossed over. Post your “definition of done” on the wall during your sprint review sessions.
Reduce planning velocity. Almost a sure-fire way to get the teams attention. Having the team commit to less (and if necessary, dramatically less) for a sprint or two will allow time for their definition of done to sink in and become a team habit.
Ensure technical feasibility prior to working sprints. I realize this is not always possible. Within our Agile Framework, the product architect (or lead engineer) should be answering the question “Is this technically feasible right now?” before moving a feature from product discovery to the team to start working sprints. Pull in the team to validate any technical assumptions made by the architect (or lead engineer) as well. If the feature is not feasible just yet it may need to be moved to a later spot on the product roadmap and an initiative added to the architecture roadmap to make it feasible at that time.
Facilitate a team quality mentality. Often times, and especially after the transition from waterfall to Agile, there continues to be a divide between developer and tester. Developers will hand-something over to the testers to test but this often occurs late in a sprint. Quality is a team sport.
All defects and bugs are team defects and bugs. Monitor how the developers and testers are interacting especially in story sizing exercises. Are the developers and testers in sync with their sizing or is the developer calling the shots? If either one is not being vocal enough a little side coaching may be necessary.
Escalate technical environment impediments. If the team is continually struggling with development and test environments, or there isn’t a production-like environment to provide confidence in the deployment, escalate these impediments through the proper channels. You many need to find the right leader in architecture or operations to make this happen but removing impediments of this type are crucial to the success of the team and in your role as a Scrum Master.
One reply on “The Scrum Master and the Pursuit of Quality”
[…] Start small but start with something. If the relationship between developers and testers has a history of being toxic in your organization it will not go away on its own and the effects of the dysfunction will only be amplified on an Agile team. Quality must be a team event. […]