A few months ago I volunteered to help hold retrospectives in our cross-functional team. Up until then, we had a delivery lead hosting most of the retrospectives and from time to time a process designer would also come in and host retrospectives.
The thing is, while we were going through the motions of having a retrospective, including creating actions – I couldn’t see any improvement that resulted from having these retrospectives (there was no follow-through with the actions). After talking to the tech director about the possibility of helping host retrospectives, I also spoke to the delivery lead about it (who was more than happy to be relieved of that responsibility as he already had plenty on his plate).
Continue reading “Learning how to hold retrospectives”
One of the things that frustrates me the most about baking is the fact I don’t tend to find out whether or not my baking was a success until the very end when I slice into that cake or bite into that cookie.
Even attempts to check out how things are going don’t guarantee good results – you can look in the oven to see if the cookies look like they are the right colour before you take them out, or you can use a fork to check the doneness of a cake or muffin, but these checks are only looking for one aspect of quality – doneness.
Continue reading “Waterfall, Baking and Slow Feedback”
If you haven’t already, you may one day find yourself in a project where there are no (explicit) requirements or very little requirements to go off.
Software can be created from conversations and assumptions. People may also assume that the little requirements they do write is enough to easily code against or test off, but then you later realise that the few lines that have been written actually pose more questions than provide answers.
You first time testing on a project without requirements can be a bit scary but I’m hoping this step by step guide will help you. Continue reading “Step by step guide: Testing without requirements/ little requirements”
As a tester, I do my best to follow the principles of Context Driven Testing.
But embarrassingly enough, only up until recently, did I realise that context can change, while you are working in a team – so anything you put in place at the start of your time in a team, might not be the best thing for everyone 6 months later, or 12 months later.
I’d like to share some things I’ve learned about testing in a changing context – but first let me describe my initial context and how it changed over the course of roughly 14-15 months. Continue reading “Lessons Learnt: Testing in a changing context”
I first came across the idea of Psychological Safety in 2017 when I attended Joshua Kerievsky’s talk on Psychological Safety at Oredev. Continue reading “Scrum and Psychological Safety”
For Part I go here
Devoting time and effort – when I have it
While I’m on my project my priority is as a tester in my scrum team. Therefore, I only devote time and effort when I have it. Some weeks I’m very busy in my team and barely give the CoP a second thought; other weeks I have more time to prepare a presentation or approach people to give presentations (or look up topics to see what people may find interesting to hear about from others).
I really appreciate the flexibility. While there is an expectation that something happens regularly, it seems that definition of “regularly” has become roughly once a month. Continue reading “Reflecting on leading a Testing Community of Practice Part II”
For about 4-6 months, I have been leading the Testing Community of Practice at my current project. Before then there were 4 of us being co-leads (for 6 months ish) before I was approached to see if I wanted to drive it and be the lead. I said yes – and said I wanted to see if I was a good fit as a lead, if I had the energy/desire for it and if there was a need/desire for a Testing CoP in the first place. Continue reading “Reflecting on leading a Testing Community of Practice Part I”