Weāre back from break and Adrian P. Dunston is enthusiastically explaining that sometimes āpeople are not at their bestā and that we would do ourselves a great favor to consider testing āwhen we are not at our bestā. Think about a self-checkout machine in a store at 2:00 a.m. Have you ever wondered what type of people are using these machines? Drunk people, sleep-deprived people, agitated peopleā¦ in other words, people when they are not necessarily at their sharpest and most professional. The fact is, this is when people do stuff and they show their humanity. They also show the largest ability to compromise our systems because of people who are not at their best all the time.
The story example above is how Adrian suggested we could put a little tester into our head that may be a little different than the person sitting at the computer at any given time. How do we do that?
Repeat Yourself. By looking at things and saying the same things, again and again, we may see something different in the process that we either did not see or chose not to see before. Having some simple catchphrases can help here. Adrian has a cool list but Iām somewhat fond of two. āWhat if?ā and āSo?ā
Keep and Tell Stories. We tend to remember things in metaphor better than we do raw facts. Myths are so strong in a culture not just because of the meaning but because of the imagery it provides. Iāve frequently looked at ways to consider explaining situations and to put it into a story method. Additionally, I like to use scenarios and personas so that the people we are dealing with are not abstract but relatable and immediate. Sometimes I take this to goofy levels. I at times annoy my team members because I will create scenarios around anime series that I enjoy. Seriously, I have several accounts that are built around the narrative of the manga and anime āBleachā. Usernames, pictures, interactions are based on those characters. People used to think it was silly, but over time, they all got used to the relationships and the details of the characters, so that they started to see that when a character they expected to see one place appear in an unusual place, they recognized itā¦ without even really knowing the minutiae of the story in question.
Slow Down. Donāt mistake speed for effectiveness. Just because we are moving fact and feel like we are in a flow, that flow can be an illusion. By stepping back and looking more carefully and yes, deliberately breaking the flow, we can see issues that we otherwise might speed over or ignore.
Argue Effectively. There are times where we have the ability to advocate for things and times where we canāt or itās not practical. A favorite phrase I remember from working with a company some two decades ago made a case about their filtering and firewall technology that āwe block you from this now but you can have it laterā. Strangely, that little like has stuck in my head all these years and itās actually something that I use for advocacy. Rather than argue about every little issue, I try to theme and make situations visible in broad strokes. At times, I tell developers that these are issues that we should address but the decision is the product owners. Rather than just grill over and over again that there is an issue here, Iāve found it to be more effective to walk people through the issues and then let them ponder it for a while. More times than not, Iāve been effective in encouraging change through this approach. Iām still arguing for quality, but Iām letting the ramifications be felt and seen. Itās not an immediate payoff, but it does yield results over time.
Set the Expectation. If you want to encourage people to see you as a strong advocate for quality in an organization, you have to be that strong advocate. You have to choose to be visible. You have to choose to be that person who will go to bat for the team.