I’ve implemented coaching within my test team. To me, this is a natural progression from the coaching work I’ve been doing on Skype.
Its early days yet, but I can already see the power of this approach to upskilling testers in a team environment.
I’ve been working on implementing coaching into my team for a while now. I was a little cautious on how to approach coaching in a work environment because the dynamics are a little different.
When I launched the program within the team I made it clear that:
1) Coaching was optional, its not mandatory .
I made this clear because its better that the tester owns the learning. I want them to feel they are in control of their learning. No-one is forcing you to be coached.
2) Coaching is not linked to performance reviews
I know this occurs in some organisations, but for my purposes I wanted to clearly distinguish between the two, so testers could feel they could discuss topics freely.
3) Coaching is focused on tester skill.
I wanted to make it clear I wasn’t a counsellor. This coaching was focused on becoming better tester’s improving skill. What the tester wants to learn and improve is up to them.
On the logistics side, I’ve booked a 1 hour session on a monthly basis for each tester. Initially, I blanched at putting this amount of time aside, but after some coaching, I’m convinced it’s worthwhile.
Its given me an opportunity to have a chat with testers I’m sometimes not fully engaged with. This is especially the case if a team lead is involved and I’m a bit distant from the tester. It helps me understand how the tester is doing, wether they are enjoying work.
It’s given me an insight into what tester’s want to learn about. I’m amazed how practical the questions are. In fact, it sometimes makes coaching a litter harder.
The challenge in coaching is not to answer questions but help them discover the solution for themselves.
I’ve adapted some of the approaches I use for Skype coaching. For example, I use tasks to help a tester understand the dynamics or complexity of a problem that seems simple.
An example of this was one tester who was frustrated at the lack of test procedures within the organisation. She felt sometimes she simply didn’t know if what she was looking at was the right or wrong answer.
I can empathise with this, especially, when your a young tester working on a complex and technically challenging product. The simple answer here would have been to suggest she speak to a senior tester or stakeholder to find out more information. But I felt this wasn’t the real problem here. Even if you do have procedures, that doesn’t mean they will provide you with the full information. What happens if something occurred that was outside the procedure. Then what? Does it get ignored?
We ran through the calculator exercise, a challenge that Mr James Bach kindly allows me to use in my coaching sessions.
This really helped her understand the complexities of testing software and how we can’t rely solely on the information provided to us. Even then our job is remain skeptical of the information we are given. The tester had many questions and the hour flew by quickly. I summarised up what we had gone through, and suggested some further reading on some areas.
Time will tell if the coaching is really effective, but I left the coaching session with a clear sense of how powerful coaching an be in this environment . I see this type of coaching in testing teams becoming an effective tool in helping testers self learn.
