The SQA2 Blog: Advice Center, General
Resist change and your organization will soon be out-paced by more nimble competitors. As many companies have proven, organizations that refuse to change are regularly left in the dust by those that can adapt, change and improve.
Change, as we all know, is hard
That said, the unfortunate reality is that the mere suggestion of change often meets with resistance. It can be scary to do something new. You have no idea what the result will be and how it will all play out. Even if someone with a great deal of experience in that subject claims that their way will actually make things better for you, it can still be very difficult to buy in to change.
Process improvement, for example, sounds great “on paper,” but is often very difficult to implement. Why? Because at its core process improvement is change. Yes, it is change for the better (or at least an attempt at better), but it is still change.
For example, a few months ago a software development group brought us in to help alleviate the QA bottlenecks that were slowing down their product delivery. After reviewing their processes, one of the first recommendations we made was to have the developers and business stakeholders review QA’s written test cases before the tests were run. In other words, we implemented a process improvement.
This particular recommendation is a proven best practice that enables missed requirements, misunderstandings and miscommunications to be caught early on, thus preventing bugs from getting out into production.
The responses ranged from “we don’t have time” to “that’s not how we do things” and “we think that reviewing test cases is QA’s job.” In other words, we ran up against the typical resistance to change.
What are the best ways to deal with this resistance to change?
At SQA2 we don’t just come into a company, observe their processes and make recommendations for improvement. We embed with the development teams to actually help do the QA work. An advantage of this is that it gives us more time and opportunity to convince teams to change.
Here’s what we’ve found works best to win people over to new ways of doing things:
- Start by observing. Seek first to understand. Look at things from their perspective. Get a good understanding of their current processes and why things are being done in these ways.
- Take a collaborative approach. If you come in and demand that things be done differently “because I said so,” you’re not going to get a particularly warm reception. Instead, try to get the team to buy into the mindset that it’s “us against the problem,” not “all of you versus me.” Get them to see that there’s a problem here and everyone is working together to solve it. “Here’s an idea that I’ve seen work at many other organizations.” “Perhaps we can try this approach.” Etc. The idea is that you’re all thinking it through together and arriving at a conclusion. Change is not being forced on the team.
- Suggest incremental changes. Even if there are many things that need to be changed, don’t try to change everything at once. Make incremental suggestions and tweaks. Win small battles and build trust over time. Let everyone see the success of those small changes and get them into muscle memory. Once one new thing is established, move on to the next thing. Of course, another issue here is that if you change everything at once you won’t be able to tell which changes were successful and which were not. An incremental approach allows you to measure each change to be sure the impact was positive.
- Avoid escalating a negative situation. If people are openly hostile to your recommendation, try to stay emotionally neutral and focus on the issue or problem you’re trying to help the group overcome. Never attack the person who is attacking your idea!
- Use data to prove your case. If you cannot overcome resistance, often the best approach is to let things play out. Monitor the process and the outcomes. Keep track of each time where a process has caused issues or failed to meet expectations. This data can be used later as ammunition to prove that a change in necessary.
- Make use of the Sprint Retrospective meetings. Most Agile teams end each Sprint with a Retrospective meeting at which they look back over the Sprint to see what went well and what did not. These meetings are an excellent opportunity to bring up the fact that a process is not going smoothly and then present your suggestions for addressing the problem.
What if people agree to change but don’t follow through?
Quite often everyone will agree to try a new process, but then quickly fall back into old habits. In this case it can be helpful to send system email reminders about the change. You should also be sure that their manager is on board with the new process, so that the manager can help enforce the change. If it’s just one particular person who is not following through, approach them in private (never in front of the entire group!) and politely bring the issue to their attention.
Another strategy is to see if there’s a way to make the process easier to follow. For example, is there a tool you can use that would make things easier, such as one of the many Retrospective tools or other online resources?
Use metrics to encourage change
What else can you to do encourage change? One thing that we’ve found to be extremely effective is to present metrics supporting the benefits of the change.
For example, one of our clients was finding that the Sprint Review Meetings at which they demonstrated completed items for stakeholders were starting to drag out to two or three hours. Even so, this still wasn’t enough time to do demos on everything. We suggested that small tickets for simple items, such as adding a new banner or new text to a page, could be demonstrated via email instead of in person.
When they resisted this suggestion, we ran the numbers. We showed them exactly how much they could save in time and money by not having to pay the entire group to sit through another hour or two of face-to-face meetings just to go over something that can be easily approved via email. These metrics convinced them to agree to the change.
In addition to showing time and money savings, metrics can often be used to demonstrate how a suggested change can ease the team’s workload—something that most people get quite excited about.
Changing from manual testing to testing automation is a great example of this. When the QA Manager at one organization was resistant to bringing any automation to her team, we helped her to understand the advantages of automation. Testing automation would enable them to test more quickly, find bugs more quickly and be more efficient overall. She didn’t see the light until we showed that testing automation could solve their QA bottleneck problems: The regression tests that had been taking her team three days using manual testing methods could be completed in just one day using automation. That metric convinced her to make the change.
Resistance is futile
When a development group’s processes are broken, resistance really is futile because the eventual outcomes will be so negative. Without change things will fail. QA will be a massive bottleneck. Bugs will get into production. Users will be unhappy. And so forth. Although change is almost always difficult, in these situations change really is for the good of the team and the organization.
