Beaumaris Castle – Steve Collis from Melbourne, Australia, CC BY 2.0 https://creativecommons.org/licenses/by/2.0, via Wikimedia Commons
A little while ago was the return of LLEWT, a peer conference on Anglesey in North Wales. We stayed in the beautiful town of Beaumaris, with a trip to Bangor on the Friday. Saturday was conference day in Llandegfan at the village hall, no soulless hotels and bad coffee here. Sunday was an optional walk down the beach to Ynys Llanddwyn. It rained. No damp spirits though, it was all organised and delivered in relaxed style by Chris, Joep and Alison.
There were familiar and new faces, people I had spent time with and some only from afar, on conference programmes, meetups and blogs. The full participant list was:
- Ash Winter, @northern_tester
- Berwyn “B” Mure, @beemure
- Chris Chant, @choibot
- Elizabeth Zagroba, @ez@chaos.social
- Gwen Diagram, @gwendiagram
- Irja Straus, @irjastraus@mastodon.online
- Joep Schuurkes, @joeposaurus@chaos.social
- Neil Younger, @norry_twitting
- Vernon Richards, @TesterFromLeic
As my career in the conference sense has progressed, I have found myself enjoying the one to a few broadcast of a peer conference, rather than one to many in a big hotel conference room. After each experience report, a facilitated discussion allows exploration of topics raised during the report. You can get into some real depth, which I find very valuable. It is on a weekend and requires a large commitment of time and money but if its within your gift, then try it at least once.
If you don’t know what a peer conference is, have a look at the excellent guide on the AST Github:
David Medcalf / Disused windmill in Llandegfan
For me, a few threads came out on the day that stood out:
Start with practices teams know something about
In the testing and quality space we often talk about how we can advocate for better practices on development teams. I think however we sometimes start with practices that teams are completely new to, which makes life very difficult for ourselves. If you start with a practice that the team has knowledge of, this is a path with much less resistance. For example, asking a team that doesn’t currently do unit tests to start with test driven development is likely to end badly, even if you are willing to teach intensively. If a couple of team members did automated integration tests for webservices (for example) elsewhere, then start there. It reminds me of a conversation at DEWT a few months ago; just what is it that we advocating for as testing and quality coaches on development teams? We often blunder in with the wrong angle. I include myself in that statement. Start where you are, rather than lament where you should be.
Testers being in the room
The specific example here was sprint planning, but could be many other ceremonies. Testers were no longer involved and my mind immediately went to the scenario that they had been excluded in some way. The reality was that the reason was not known. I shouldn’t allow my assumptions to get ahead of me. Being in the room is a big topic for testers, as its a place we are often looking into from the outside, without the opportunity to ask the big questions (‘How will we test this’ and ‘How can we make this more testable’ in case you were wondering). Organisations are complex though and there can be lots of reasons for not being in the room. Once you are in the room as a tester, supposing you want to stay, my general thoughts are; Try to offer a point of view that isn’t already in the room, talk about risks but with delivery in mind.
I once met a tester who proudly said he could come up with hundreds of reasons any feature he analysed couldn’t or shouldn’t be delivered. He wasn’t in the room.
Technology function ‘underneath’ product
Throughout the day, we talked about how our organisations are structured. One common pattern was for the technology function to ‘line in’ to the product function. This relationship has always been one of tension in my experience. In a past role, after a particular outage, the product function said that the technology function should ‘have a long hard look at themselves for causing this problem.’ I argued that it was all our behaviours that got us there, every decision taken together from product design and technical architecture onwards, so maybe we could include those in the review too. The answer was no.
Product and technology need each other. I think that technology delivered via whatever products goals are could lead to low quality, hard to maintain architectures. If the technology goals led the product you might end up with a technically competent product no one wants. It probably comes back to the whole, being reasonably aligned, having meaningful shared goals as well as your own and building effective working relationships. What it always comes back to.
Ynys Llanddwyn view with lighthouse – Alun Williams333, CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons
One of the things I love about LLEWT is that its not at a hotel or dedicated conference venue. Whatever we brought in and whatever mess we made throughout the day we had to clean up. There is something theraputic about working together to clean up after the conference, setting the village hall back to what it was, ready for the next community group to use it. It is a great way to finish another enjoyable and thoughtful LLEWT.
Diagram Industries 