Dahlia Season Consulting

Originally published June 20, 2016 on cocktailmonkey.blog.

Bring Out The Breaker!

I’ve had many teams actively employ the breaker mindset at critical times during product development and vastly increase the quality of the product as a result. These are a few of the practices that have I seen bring major improvement:

• During backlog refinement: one or more people take on the the breaker mindset to walk through all of the errors and edge cases that must be accounted for in any give feature or story. This often happens in the form of questions from the breaker. The outcome is captured as acceptance criteria or technical acceptance criteria in the story.
• The first step in building a story: when a story is first started, two people sit together, one builder and one breaker, and review the story, its boundaries, and all of the acceptance criteria. They fill in any missing AC, then task the story and start development of tests and code.
• The last step in building a story: a team member who wasn’t involved in developing the story does a technical acceptance. This includes looking at the story, acceptance criteria and technical acceptance criteria, and verifying that everything has been implemented to the teams standards. They verify that tests exist and pass at the appropriate level (i.e. unit, integration, system, UAT). They may comment out code to ensure the automated tests can fail. They also try to see if there is any way to break the feature that has not been anticipated. This person also looks to see if the teams coding standards or any other agreed upon practices are met. Once this technical acceptance is done, the team works with the Product Owner for his or her acceptance of the work.
• During mid and long term planning: taking a critical look at what can go wrong during the creation of a larger feature. When the team gathers to look further ahead in their backlog, or when they are decomposing a large feature, identifying what the major risks are is critical. The team can ask itself questions like these:
  • What part of this feature is the most technically difficult?
  • Do we need anything that’s difficult to get? Perhaps hardware, or the time of an expert?
  • Are we familiar with the code we’ll be working in?
  • Is there major technical debt in the code we’ll be working in?
  • Do we have anything going on with our team members that could potentially disrupt the building of this feature? Is anyone expecting a baby and going on maternity or paternity leave? Are any long vacations scheduled?
  • Are there any organizational habits to be aware of? Do stakeholders look at this type of feature very critically?
  • If the feature is being implemented by more than one team, do we have a plan for cross team communication?

No Tail!

I have found that employing the breaker mindset can be a critical step in increasing the quality of the code written the first time around. It can also flip the team to a test first approach, which helps eliminate the story tail. That tail happens when the coding is done, but the tests don’t pass, or manual testing finds bugs. That instigates a cycle of fix and retest that can add days to the creation of a story, and may contribute to a team missing their sprint goals.