Teaching is similar to specifying

Over the past couple of weeks I spent some time training a student-trainee who is about to graduate in marketing. She is going to work with Alter Eco, a software service company I support, in the field of marketing and sales. So, providing some training was an important first step for her to be able to be part of the team in a productive manner. That is how I came to think about the many similarities between teaching a subject to someone and building functional specs in the context of a development project.

When I want to teach something to somebody, there are several steps I have to go through, which are essentially the same as those I have to execute when discussing functional and non-functional requirements of a business with a delivery team:

1. command -  my own understanding of the subject must be crystal clear or at least I have to be disciplined enough to say "I don't know and I will look for answers" when I don't know instead of making erroneous assumptions;
2. see the world with the learner's eyes - I must put myself back in the situation I was in when the subject matter was fresh knowledge and I had to apply it step by step, because otherwise I will just omit things that are essential and now seem so obvious they shoudl not even be mentionned;
3. use the learner's language - when presenting the topic, I must use words and images that have meaning for the people I am working with;
4. seek feedback - it is necessary to check on a regular basis that the message is clear and to invite comments and questions. When a question is interesting I must seize the opportunity it represents to provide information as it is requested because that's when attention is at its peak. That is even if answering the question totally changes my game plan for the training session;
5. use metaphors and stories - metaphors and real-life stories are just great tools. That is one of the reasons why I like so much the principles of the Agile Manifesto;
6. involve the audience - each time a logical unit of the training has been delivered and discussed, it is great to invite the audience to sum-up the points that where presented;
7. focus on exchange - as a general rule, training is about exchange not about a monologue... which alos has the benefit of keeping everyone alert. So I kind of like situations where the "learner" ends up teaching stuff to the "trainer" or helps him / her see new connections between ideas and topics. Which is another reason why agile methods make so much sense.

So, I guess that poor training skills could be one of the reasons why there have been horror stories at times with bespoke development projects: somebody who is a functional expert in a given field for which a software tool needs to be built is not necessarily very good at presenting his activity... Then the question becomes: can a good "student" / "learner" / "investigator" / "analyst" ensure decent specifications are built by asking "the right" questions? I personally think so, but by now you must know I am a fan of questioning, a "questioning agent" if you will... Which explains the logo :-)