As we reach the spooky season I thought I’d muse upon a horror story in software development; our in house practices are making things worse. I’ve grown to shudder when I hear the words “we’ve always done it like this” as it signals a non optimal situation that we’ve accepted and that we don’t want to change.
But why is this a problem and more to the point what can we do about it?
“We’ve always done it like this…”
I’ve worked in a number of different companies as a software tester, each having their own challenges but none so much as a team who can’t (or won’t) learn. In these teams I’ve found a number of bad quality practices such as siloed testing, not sharing information and scrummerfall practices where testing was ignored or pushed out. The common thread was that people had accepted these in house behaviours and any discussions about them led to a shrug and a statement of “we’ve always done it like that”.
Embedding into the team I’ve seen a number of issues that come out of this kind of behaviour:
- Not seeing the issues anymore – People have accepted that things will be as they are, they don’t question that things are slow, that defects happen or that people are unhappy.
- Monoculture – People aren’t questioning or improving how we behave, instead relying on “the way we’ve always done things” which creates a company-wide monoculture. This means a lack of diversity of thought and the teams just agreeing that there’s only one way to do things.
- Knowledge silos – Process or knowledge is so bespoke that it can’t be intuited and people keep that knowledge in their heads (so they won’t become expendable). They guard this knowledge and push back on behaviours to share information as this might erode the need for them.
- Can’t push testing left – In these environments we frequently can’t question things with an intent to change them. Discussions about “why?” are usually halted with “because that’s how we’ve done things” so we can’t influence quality or behaviours.
These types of in-house practices can also extend to testers. Instead of looking for information and learning about the system to inform quality they rely on their in-house knowledge of the system to confirm what they already know rather than explore to find out what we don’t know.
- Testing to scripts / to knowledge – It’s easier to do what we’ve always done rather than try to do something new. Rather than using testing techniques these testers can focus on their system knowledge, being an SME to the system rather than a quality investigator. They can gate keep system behaviour rather than try to inform on it and push back on attempts to improve processes.
- Sharing statuses and not information – Rather than trying to share information, testing is kept abstract through the reporting of metrics and numbers. We’ve always had testers tell us what’s good.
- Pushing back on modern testing techniques – Automation? Nope. Exploratory testing? Nope. That all seems too hard and wouldn’t work for our company because we’ve always done things in this way and people couldn’t change…
Why does this happen?
People inherently want to do a good job; it’s not in their nature to deliberately make things worse or derail things. As such we should look to the underlying reasons why they might fall back on suboptimal in house practices rather than try to change things.
- People are in too deep – They don’t know what they don’t know. Perhaps they’ve worked somewhere for many many years and assume that’s the best way to do things. There’s also a sunk cost fallacy where people are less likely to think that something they’ve done for years might not be a good way of doing things.
- Time constraints – If we’re always firefighting and in a rush to get things done then they might not have the time to think about improvement to processes. We just need to follow the patterns that we know to get this done and survive the next release.
- Environment of no innovation – We might have a company where management dictates behaviour and process and we’re not empowered to push back. The team members might want to try something new but there are road blockers to this.
An environment where we have a reliance on in-house practices or where there’s a closed mindset to change can be really difficult to work in. As testers we strive to uncover and share information to enact change, so meeting a constant barrier to that does not feel good. If there’s no appetite to change ever and no safe space to challenge ideas then we can’t learn and develop as a team or as individuals.
In these environments I’ve found that I usually end up in one of 3 situations:
- Giving up and following the in-house processes.
- Speaking up with it not being wanted, driving a wedge between me and the company.
- Sometimes speaking up will enact change.
In situations 1& 2 I’ve felt like I couldn’t give much to the company and that the company couldn’t give much to me. It made me feel frustrated and anxious so I ended up leaving.
What can we do?
Situation 3 can happen, we can push back on ways of working and see things change. Through testing the ideas of the system and our processes people listen and say “that’s a good idea”.
- Question things: Pick your battles and question some of the in-house processes that need changing. Don’t try to change everything at once but instead target change where it’s really needed. Where people “have always done something that way” try to find out why, or what barriers they have to doing things differently. Maybe the only blocker is an assumption that we can’t change, or the fear of change.
- Inspire people: Rather than berating people for how they’re doing things, show them what can be done. Win people over with a proof of concept to show that new ways aren’t scary and that they can work. Start with your own work and change that, I’ve embedded exploratory testing into scripted testing companies via my own work and showing people how it can be done.
- Back up people who speak up: Be an ally and build on the voices of people who speak up to challenge the monoculture. Adding voices to a discussion can help to enact change.