So we had a new guy start in our group last week.
Normally, this would be cause for great joy and celebration (actually, it still was) but there were a few flies in the ointment related to the fact that he started now. Brendan (his boss) was scheduled to leave for Germany early this week to speak at our European Forum, and of course had preparation work to do. We’re going into a heavy crunch time in the team room. (Did I mention that we’re working in a team room?) We had a holiday weekend coming up. And so on, and so on…. In summary, none of us had a lot of bandwidth to devote to training.
Back when I was running an ACIS team, we would have sent Julian (the new guy) to the training class we give our customers to get some general familiarity with the product. Then we would have spent a day or two showing him how to run our source control and build tools and generally get him set up on his machine. Then we probably would have given him an easy bug with lots of education potential and let him debug through it while figuring out the code, interspersed with a lot of answering of questions and discussions of the theory behind how ACIS works.
But things are a bit different now. We’re working in the team room on productizing CGM, so we don’t have a lot of educational bugs to give him. In the team room we’re doing a lot of pair programming and project ownership is more diffuse. And most of all, as mentioned above, we just didn’t have a lot of time to devote to training due to the various crunches.
So we decided to wing it. One of the big advantages of working in the team room (we’re doing what is essentially a flavor of Scrum with two week sprints) is the training potential. Since there’s discussion about all the stories we’re working on, everyone on the team gets at least a little knowledge about what’s going on. And I’m firmly convinced that one of the major plusses of pair programming is educational – knowledge gets spread around much more efficiently than through lecturing (or not talking at all :). So we said, “we’ll just throw Julian into the team room and let him ‘pair’ on whatever will be most educational at any particular time” (the quotes around pair are meant to indicate that we didn’t expect him to be driving much while pairing).
That was the plan: to do a lot of pairing. But it wasn’t quite what happened. What happened was that Julian spent most of his time following either Brendan or me around watching what we were doing. If we were programming on something, great – he paired with us. But if I had to walk down the hall to coordinate with someone about what we were working on, he’d follow me and watch. And about half way through the week I realized that what was really going on was that we had Julian shadowing us.
The reason I’m familiar with shadowing is that I eat out a LOT. Have you ever sat down at a restaurant and had two servers walk up to your table at which point server #1 says “Hi, I’m Allison and I’ll be your server today. This is Bob – he’s in training”? Bob is a new hire and he’s shadowing Allison. It’s basically an unstructured training regime which emphasizes learning by immersion in the actual work environment. Most restaurants start a new hire out by having him shadow someone else for a week or so, after which they switch roles and the trainer shadows the trainee for another week or so before the trainee finally goes solo.
After the initial light bulb went off in my head, a second one went off right away. The restaurant industry probably trains millions of new hires every year. It is reasonable to assume that they are very good (read: efficient) at training people. So picking up one of their standard training techniques and applying it on our new hire was probably a really good idea, albeit one that we didn’t realize we were having. And it seems to be working out; I feel like Julian’s got a much better feel for what we’re doing and the issues that we’re facing than if we had given him an easy project. And it didn’t suck away huge amounts of our time. And he was even able to help us out on our crunch work this week. I’m planning to recommend that we use it (consciously, this time) as a standard technique when training.
Has anyone else used this approach to training in software development?
