The SQA2 Blog: General
The new feature release was an utter disaster. Almost as soon as things were released into production the customer support calls started pouring in. This didn’t work. That didn’t work. Things were crashing. The application was now riddled with so many defects that we actually had to roll back a long list of features.
When the dust settled there was plenty of blaming and finger pointing to go around. But the ultimate cause of the fiasco was a breath-taking lack of communication. The developers had been pushing out feature after feature without communicating this to Quality Assurance (QA). So when QA did regression testing and minimal testing, these new features were not properly tested. It’s pretty difficult to test something that you don’t know exists!
The solution was obviously to put better processes in place around communication. But how do you communicate the new processes themselves?
Successfully communicating processes requires a multi-layered approach
As QA professionals and consultants, we’ve seen that you cannot simply announce to your development team, “hey, everyone, here’s our new process!” and then call it a day. There’s much more to it than that.
Communicating new processes involves overcoming resistance to change. Before people will be open to change, they must first understand that there’s a problem with the old process…which means you might need to start by letting the group fail doing things the old way.
Once the problem is more obvious, here’s what we recommend:
- Bring up the underlying issue at a Standup or Retrospective meeting. Most development teams have daily Standups and regular Retrospective meetings. These are excellent opportunities to bring up the fact that the current process is not working.Of course, how you communicate this is very important. Avoid having an aggressive tone and/or demeaning the existing process. After all, the people in the room may be heavily vested in the existing process. Instead, take a collaborative approach.Make suggestions. Share the evidence that things are not working and present ways to improve or replace the broken process. If you have metrics to back up your contention that the current process is indeed broken (such as the number of product defects that were released into production), present these in an easy-to-understand chart or graph. Explain how your suggested process can be incorporated into their existing team structure. Instead of forcing something on everyone, include the team in discussing and developing the new process.
- Present the new process in person. Once it’s been decided that a new process will be implemented, do so face-to-face, such as at a Retrospective meeting. Use visuals to help everyone understand the new process. Visuals that show what the new process will look and feel like can go a long way towards getting buy-in! If, for example, the team is using a particular tool, show how the process will work within that tool. If you’re suggesting bringing in QA automation, provide a small demo of what the test cases and the reports of test results will look like. Use the visuals to get everyone on board with the new process.
- Send an email or other digital message as a follow-up to the meeting. Reiterate why the new process is needed and the results it is expected to bring. Provide a written explanation of exactly what the process is—who will do what, and how and when they will do it.
- Reinforce the new process with training. Sometimes it’s not enough to announce the new process at a meeting and follow-up that announcement with a detailed “how to” email. You might also need to provide in-person training.This can also be true when you release a new application feature. In addition to letting people know the new feature exists, you often need to train them on how to use it. This is especially the case if there are multiple ways that a thing can be done, but just one particular process that you want people to follow.
- Get the team leadership involved. Leadership should always be a big part of process improvement. The Team Lead, Lead Engineer, Product Manager and/or Department Tech Lead should receive all communications related to the new process, help communicate the new process out, and take charge of enforcement.
Communicate the fact that the new process is working
Once a new process has been communicated and implemented, you need to follow up. Capture the metrics. If the new process is working, share the wins! Send emails or messages through the team’s messaging system (such as Slack), announce the metrics at Retrospective meetings, etc. This will help build support for future process changes.
Of course, if the process is not working, make changes as appropriate and then repeat the entire communication process.
