Earlier in the week I had to deliver a training session to one of our most recent additions to the technical team. He’s been there 3 months and, arguably, I should have provided this training already but I wanted to try something different.   

A “good” employer tends to pride themselves on the fact that they deliver hours, sometimes days, of training before a new pin can actually get on with some work. Invariably the Health and Safety Stasi and someone with a week long ”Post-Educational Higher National Secondary Certificated Diploma in HR” get in on the act and the bright, enthusiastic new team member has the will to live sucked out of him/her over a matter of a few days whilst they answer pop-quizzes about correct lifting techniques and the location of fire exits.  

I’m lucky. I work in an entrepreneurial environment and can try things out without the aforementioned Stasi breathing down my neck asking why I was submitting the appraisal forms of my grade 14 staff 3 working days late. I’m also lucky in that I only have to deliver scrum training, which is one of the most straight forward things in the world to do. What makes it particularly easy is that, unless you’re some kind of Scrum fundamentalist, the scrum community does not present Scrum as the panacea for all the ills of waterfall (or chaos – depending on your alternative). Scrum training is not a matter of indoctrination, it’s more of a “well, this is how we choose to do it around here, and it’s not perfect but it suits us” type conversation.  

The manner in which Scrum training is delivered should reflect the themes or the principles of Scrum/Agile itself so I always try to apply the Agile manifesto to the training environment.  

Agile Manifesto

One or two of these we can take verbatim and apply them to the training context very easily but others need a bit of metaphorical treatment:  

• “Individuals and Interactions over Process and tools” can be quite easily applied. Scrum training sessions chez moi are informal affairs and for each one the style of delivery is tailored to the group.
• The principle of “Working software over Comprehensive documentation” too applies well to the training environment. When software works, it does so because the requirements have been correctly reflected in code and the developer’s understanding crystallised. In a training context, if you see someone taking exhaustive notes about what you’re saying, they don’t “get it”. Scrum is not something you can learn by remembering, it sits firmly in the “learning by understanding” camp. If you see somebody you’ve trained at their first scrum referring to notes to see what they should be doing, you’ve done a bad job!
• “Customer collaboration over Contract negotiation” in a training scenario is a curious one. Its application in an employee training scenario is, though, quite simple. As I said earlier in the piece, I never present Scrum as a panacea, merely, “how we do things around here”. Furthermore, I don’t present it as a rigid framework. The trainee(s) must, rightfully, feel that their input in the team does not extend only to the work output, but the method of working itself. So, the new team member can, in his first retrospective, completely change the manner of working if he can achieve the agreement of his team members. Scrum will never be a rigid framework, at least in application.
• “Responding to change over Following a plan” should apply to any training environment, not just for Scrum training. Sure, there’s some knowledge to impart but any decent trainer knows that the best way to impart that knowledge to a group will depend on many factors. If the trainer doesn’t adapt to that, (s)he is lost.

I’ve attached the slide deck that I use to train Scrum. It has come from a mixture of sources, including www.mountaingoatsoftware.com (from which the basic framework was sourced) and a friend and mentor (and exceptional Scrum trainer to boot) Sean Sullivan. The Mountain Goat framework has been significantly enriched by Sean, placing Scrum in a theoretical/academic/evidence-based context. I hope some of you find it of use. I don’t ask for a mention but it’s important, at least to Mountain Goat, that you retain their references.  

Click here to download the slides (Powerpoint 2007 format)

Click here to download the slides (Powerpoint 2003 format) 

I’ll let you all know in another post whether the late training worked, or not but, a parting message:

Train early or train late, make sure you train and if you’re training about agile, train agile!

A side note -   

I don’t like the word “training” as applied to the general knowledge enhancement of humans. We train animals, we educate humans. However, who’s going to Google for “Scrum Education”?