Scrum Master Scientists and Picasso Developers

“There’s a  scientist in every Scrum team” – This is something a pretty well-known automation tester said to me during a conversation we had after he’d recently completed a contract where he was helping to establish the automation function for a company in Leicester. I love applying a label, unsuspectingly to people unaware, so I dug for more! What do you mean?

Developers write code to paint a picture – that picture takes form as a website, desktop application, tool etc. But it is essentially [technical] art. They’ve created something that has personal value, as it’s entirely unique to them and is an individual piece of expression. No developer would have painted the picture in the same way as the above [theoretical] developer, ever. They could create something that achieves the same purpose or performs an identical task, but it won’t have the same lines of code and it probably won’t have been written in the same style.

Testers on the other hand [some would argue] are more like scientists. They don’t build anything (other than tools and frameworks, used to perform their science), instead, they start with a proposition. Often that proposition comes in the form of “this piece of software works” and testers work to either validate that claim or take a sledgehammer to the claim to demonstrate that it categorically doesn’t work as suggested.

It’s an interesting differentiation and is something I only became aware of because a tester who used to be a developer posed the idea to me. It really got me thinking, because Art and Science are both, frankly, awesome. They’re both also very different.

Some of you might have seen a speech delivered by Tim Michin (full speech here), an Australian comedian who spent a portion of his life in the UK. He makes a point that art and science are at odds with one another, he references the Australian PM at the time not believing in climate change because he’s religious. He explains that artists and scientists need to do a better job of communicating to overcome their differences and achieve their goals. Now that I have another perspective – that understanding the differences between Developers [Artists] and Testers [Scientists] – I can’t help but think this is a very similar point to the one raised by dev teams and testers time and again, communication is key. You hear about it at countless conferences, events, meetups, talks, online discussions etc. etc.

At the Octobers DevOps Nottingham meetup at the Rebel office [shameless plug – next one coming up  Tuesday, January 28^th!] there was a talk on collaboration and communication, how teams do it and some advice on how to frame our questions, particularly tricky ones, to better come up with solutions. Some bits in particular resonated with me personally, that focused not on how we receive information, but how we deliver it and what we should consider when approaching a scenario – us/them – removing the instance of putting someone in a position where they need to defend their actions or the outcomes of their actions. Achieve that and you eliminate a certain amount of tension/frustration, pronto. Putting someone in a position where they need to defend themselves simply wastes time, energy and motivation.

So, how do we communicate better to improve efficiency, create a better environment or culture? And facilitate people building confidence?

In my opinion, a good place to start is understanding other people’s roles. In regard to test/dev that may mean understanding that a developer could well think of their code in a somewhat artistic sense – it’s personal and unique to them so why not? And even if it’s justified to call a piece of work crap because it doesn’t work, is that really the best way to get what you want?

Most people know it’s important to have some tact when they’re communicating with people at work but thinking about how you frame your questions and how important something might be to the person with whom you’re communicating might just make things a little more straightforward, particularly if you’re not the most tactful individual, or you’re in a moment of diminished effort for tact’ing.

Let’s pitch a scenario: A dev has built a website for a customer and it needs to be tested before it goes live – obviously…

Dev: informs tester a piece of work is completed and ready for testing.

Tester: Do some testing and establish the website doesn’t let you log in if you type in Mandarin. The customer has a large proportion of Chinese users, so this is an issue.

It’s nothing to blow up about, really (is anything?), but let’s say the developer should have factored in Chinese users and built-in that functionality, you could understand some element of frustration from the tester, right? The dev’s built something and it doesn’t work for a portion of the people it categorically needs to work for. The customer might understandably be well-annoyed!

Now instead of thinking of the developer as having built a website that doesn’t work for everyone, imagine they’ve done a painting for the customer, not a website – the customer gave some guidelines and the dev gave it their best crack. How might this change the framing of the conversation post-review/testing?

Do you foresee the conversation going well if the tester explains that the art is pants because someone from China won’t get it? Probably not, and let’s face it how many artists do you know who would happily hand you a piece of their work knowing that you’re going to slash it with a knife within 24 hours of completion? I imagine it’s not many – if you know any artists at all please ask though some searching through Reddit suggested artists do not like aggressive criticism or having their art damaged. I don’t imagine (m)any artists would spend their time and energy creating something specifically to have it destroyed (unless you’re Banksy and want to revolt against a museum selling a piece they said they’d never sell).

I feel like things would run a little smoother if the tester could make some suggestions for how to make the art more inclusive like maybe include a translation of the title in Mandarin if there are going to be Chinese folks viewing it?

Okay, I need to make a point somewhere in all of this.

That point is, essentially, that communication between testers, developers and everyone else involved in building a product, platform etc. can improve if you understand and appreciate the creative element of writing code. It also helps if people understand exactly what their colleagues and peers do. We’re lucky enough that mistakes can be changed, the software is adjustable and can be edited.

Disclaimer: I realised after I’d finished this that you don’t test art or paintings, it’s objective so the premise of the whole post is somewhat redundant – though I suppose with modern art and sculptures and stuff they probably have to be tested somewhat for load and strength, resilience etc? Either way that doesn’t make the message totally pointless – we need to appreciate the effort that people put into things that are entirely unique to them.