Comments on: Coaching Testing Skills http://selenadelesie.com/2009/11/25/coaching-testing-skills/ People. Learning. Organizations. Wed, 01 Sep 2010 19:07:16 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: <img src='http://selenadelesie.com/wp-content/plugins/rpx/images/twitter.png'/> Ted M. Young http://selenadelesie.com/2009/11/25/coaching-testing-skills/comment-page-1/#comment-9 Ted M. Young Wed, 25 Nov 2009 05:51:10 +0000 http://selenadelesie.com/?p=216#comment-9 Thanks for writing this -- you're certainly not the only one facing this type of issue. I'm sure others will comment on the specifics of teaching testing skills, so I'll talk about my thinking given that I have 10 (soon to be 11) programmers who report to me (not to mention the 5 testers on the team). 1. There is an upper-limit on how much you can scale by trying to lead all of these efforts. It's time to delegate some of the learning responsibility and find ways for small groups of people (4 is about right) to meet on a regular basis as a study group. Similar to the workshops you're doing, but led by the members themselves. You can kick off the meetings, or close them, but don't spend all 2 hours in the room/area. 2. Train the coachers: similar to your first possibility, but have people dig deeper in areas of interest to them and then let them lead workshops on those areas. 3. Pair test between development and testers. Not for an entire feature, or even a whole day, but just for an hour or two. Relative to the managing part (mainly the one-on-ones), I'm finding more and more that working side by side with the people on my team by pairing and allowing the space to go "meta" (i.e., talk about how we're working with each other and with the rest of the team) during the pairing reduces the need for the one-on-ones. And I get a much better idea of their strengths and weaknesses than even they might be aware of. ;ted Thanks for writing this — you’re certainly not the only one facing this type of issue. I’m sure others will comment on the specifics of teaching testing skills, so I’ll talk about my thinking given that I have 10 (soon to be 11) programmers who report to me (not to mention the 5 testers on the team).

1. There is an upper-limit on how much you can scale by trying to lead all of these efforts. It’s time to delegate some of the learning responsibility and find ways for small groups of people (4 is about right) to meet on a regular basis as a study group. Similar to the workshops you’re doing, but led by the members themselves. You can kick off the meetings, or close them, but don’t spend all 2 hours in the room/area.

2. Train the coachers: similar to your first possibility, but have people dig deeper in areas of interest to them and then let them lead workshops on those areas.

3. Pair test between development and testers. Not for an entire feature, or even a whole day, but just for an hour or two.

Relative to the managing part (mainly the one-on-ones), I’m finding more and more that working side by side with the people on my team by pairing and allowing the space to go “meta” (i.e., talk about how we’re working with each other and with the rest of the team) during the pairing reduces the need for the one-on-ones. And I get a much better idea of their strengths and weaknesses than even they might be aware of.

;ted

]]>