When I first starting working as the dedicated tester in my current team it was a “waterfall” to testing operation. I called this out quite a few times, and, it was acknowledged we were doing this quite a lot. There is, however, a vast chasm between recognising a behaviour and changing that behaviour. As frustrating as that might be, it’s reality. People take time to change the way they operate.
The first thing that had me hoping change could happen was that the team acknowledged we could develop better habits around testing. That’s a really great thing. There are a bunch of Developers in the team and they could have easily decided that it was all too hard. They could have given lip service to idea and just ploughed on with no real intention to change.
Having said that we needed better habits around testing in the team, that didn’t exclude me. I needed to be come more alert to opportunities, ways to show the value of testing. If I was asking other to commit to change then I had to support that with a willingness to try things that might be different to ideas I had. I needed to be available to discuss ideas and I had to be very open to sharing my ideas on testing (stopping me talking about them is probably a bigger task). Not least, I needed to stay sharp during discussions of a more technical nature (that’s not something that comes naturally to me). I wanted to be able to add value in this space. I wanted to have the Developers value my input and not just ask me because it was expected they would ask.
There were four key points I wanted to occur for every story.
- Kickoff
- Collaboration
- Walk through
- Test review
When I say “occur” I really mean for them to be considered and discussed. In some contexts it might be perfectly fine to say “hey we can skip this” but let’s at least have the conversation and understand what not doing something might mean in terms of risk. These were also the things that I believed would help us make other touch points regular occurrences.
- Kickoff – a walk through of the story with the Developer, Business Analyst, Product Owner and Tester. Establishing our understanding of the story, any risks, things that we could investigate further, ambiguities not seen previously, possible impacts outside the immediate scope of the card. In short anything relevant to the story.
- Collaboration – this is reminder to us all to talk to each other during coding of the story. Talk about blockages, surprises, things we misunderstood at kickoff, coding implications, things that I might want to investigate to help the Developer, things I might want to look at or investigate to improve my understanding of what we were doing. This collaboration aspect extends to any stakeholder who has useful information or needs to be kept informed.
- Walk through – a demonstration, by the Developer, that the acceptance criteria (as a minimum) have been delivered. Generally attended by the story Tester and the Product Owner these can be quite deep sessions, even though duration is generally quite short. As a group we have rejected stories at walk through because we have seen problems in the way the story was expressed. This is a serious step in maintaining quality.
- Test review – When I’m testing I talk to people inside, and external to, our scrum team. I love to use peoples different knowledge levels and perspectives to create test ideas I might never develop on my own. This step is a reminder (to me more than anyone else) to have conversations about what I found when I think I might have tested enough. Are there other things worth probing based on my results? The context of the story determines how wide I go with chasing stakeholders.
The early sprints of moving into this new territory was hit and miss. Old habits die hard. Developers would take stories and the story kick off would be missed. The first feedback I would get was at the walk through prior to testing of code. As a team we were forgetting about the opportunities we wanted to create (to be fair there was more than just this change going on at the time). As individuals we were following old habits more than creating new ones. At times it seemed like a “path to nowhere”, but reflecting on how hard it is to change personal habits, let alone those of many people, reassured me that it was, given the quality of my team mates, just a matter of perseverance.
I was sitting, just thinking one day about the above 4 points and the “hit and miss” nature of the venture. I was as hit and miss as anyone else in the team so, even with expressed desire, the change was “slipping and sliding” more than driving forward. Maybe it was the number 4, I’m really not sure now, but the idea of creating a game and setting it on a baseball field came to mind. I whipped up a very basic outline and spoke to the team BA about the concept.
The initial plan was to add some color, name the bases, print it out, put it up. It didn’t quite happen that way. Our team Delivery Lead asked if she could maybe “expand it a little”. Seemed like a good idea, turns out it was. Here’s what happened:
Now we really did have a game board.
For the first couple of sprints or game was attached to a wall. Unfortunately the wall and our stand up were too far apart. We never really talked to the game board. Then we decided to take it off the wall and attach it to a piece of board. It is now portable and comes to stand up with the team.
We are really just getting used to using this as part of our tool set but it has produced some useful conversations. We are yet to set rules around this. When we do I’m sure they’ll increase the usefulness, fun and feeling of it being a game. One of the things we have discussed is our ability to change those bases to whatever points we feel the team needs to focus on to build better habits and outcomes.
I really like what has happened to get to this point. I had an idea that would not have had the end product appeal without other input. In reality it probably would have just withered and died. Multiple ideas from team mates made the idea into something I want to interact with, something far superior to my initial thinking. We have already seen some early signs of usefulness but, as a team, will develop the idea further (because that’s the nature of the team I work with).
I’m really hoping that in a few months I can blog again on this, our wins, our failures and how we tweaked the game to make it more useful. I also hope I can talk about how it was useful, what we learned from using the game. But then, maybe in a couple of months I’ll blog about how it wasn’t useful and why. Either way we will have learnt some really useful things about how we work as a team.
As always, thanks for dropping by. If you’ve done something similar please drop me a note and share your story.
Paul
@Beaglesays 
Way, way back in the days of yore, probably shortly after dinosaurs left the earth and certainly before the term agile was developed, we had improvements to make to reduce cost or time to delivery. We employed ‘good engineering’ and it made sense that we spoke to other disciplines to get their support. The purpose of what we wanted to achieve was very clear and the solution/s adopted were thought about, improved, actioned and sometimes needed a re-think.
Step forward a large number of years and we’re doing the same, people working together to solve problems, except we now have a snappy name for it, agile. So, nothing has changed, apart from what we now call this activity.
LikeLike