How many project teams have you worked on where the accepted culture was to rely on the QA members to bear the load for quality? As the leader of a QA meetup, I still constantly hear stories from my members about developers’ assumptions that it is QA’s responsibility to find bugs. Not only is this attitude demoralizing for QA, it is also not in the best interest of the team. How can a team change development culture to one that is quality focused for the entire team?
The answer seems obvious — Management needs to declare that all team members will have a hand in quality. This truly is critical to a successful culture change! Besides empowering dev managers and Scrum Masters to direct team activities (such as enforcing unit tests), it will give QA members the confidence to push the team as well.
But that direction to focus on quality is not enough. Why?
Adding quality assurance activities adds time to a developer’s level of effort
Developers don’t feel a vested interest in adding to their workload
Scrum Masters are often dev managers who have the developer’s mentality
No one has proven the benefits to the team
The Scrum Master is key to culture change. The Scrum Master has the ability to control sprint meetings and hold members accountable. By making quality a repeated, primary focus, the Scrum Master can guide the team to the realization that shortcuts won’t be tolerated. The Scrum Master plays a role in sprint planning meetings by making sure that acceptance criteria is documented and agreed upon for each story. During the daily scrum, he or she questions story owners to make sure quality checklists are completed before stories can actually be closed. When it comes time for the sprint closeout, he or she insures there are feature demos to provide visibility of the quality of the product. Each of these tasks plays a huge role in holding the team accountable for quality.
Ah, peer pressure. Such a powerful motivator. Have you ever seen anyone successfully and continuously resist it? How do you create it if you don’t have peers around to provide the pressure? Dun da da da! (trumpets playing) Introducing — the Champion! There is usually a strong developer the team looks up to. A proven contributor, confident in his or her abilities, and a driver for change — the key player in changing culture. If this person can become the champion for quality, the rest of the team will soon fall in step, providing the necessary peer pressure. I personally didn’t realize the power of this role until a new developer joined a team I was once a part of. He came from a strong Agile background, was outspoken, and a solid coder. The team had habitually avoided writing unit tests and participating in other quality tasks. Within just a few weeks, the developer began making comments about some of the existing code he was reusing, and said that he was able to find bugs in a high percentage of it. Much of what he found had not been readily discovered by the then-current testing efforts of the QA team. On the daily scrum, he would mention how he had solidified some code and added unit tests, telling the team how important those tests were. While it first came across as arrogant, he persisted, calling out the benefits and making it all into a positive. It didn’t take long for the rest of the team to start following suit.
Obviously, no one can expect the Champion to do it all alone. You need to do your part, too! Help educate your team about the cost of a bug. (A great post by @Greg Sypolt does just that.) Use the tools at hand. Your bug tracking system should allow you to pull all kinds of metrics. If you show your team the number of rejects for supposedly “fixed” bugs, you can drive them to incorporate automated testing during bug fixes. Track and pull reports about regressions, especially if they are found by the customer, and present this powerful data to prove your point. Better still, if the team begins to change their culture to one that is quality focused, these metrics will provide the right kind of reinforcement! Joe Nolan is the Mobile QA team lead at Blackboard. He has over 10 years experience leading multinationally located QA teams, and is the founder of the DC Software QA and Testing Meetup.