Knowledge Transfer: The Tutorial Series

Alongside the magazine, the publisher ran a training business. Its tutorial catalogue lived at knowledge_transfer.html with one detail page per course at knowledge_transfer_detail.php?id=N. Seven of those ids appear in the link record: id 2 with nine referring domains, id 4 with five, and ids 3, 9, 10 and 11 with one or two each. The only id whose subject the anchors establish is 2: it was linked from a programming magazine's events calendar for January 2011 with the anchor 'Agile Program Management', and the same calendar links the page from a second host. That tutorial is continued on this site by the agile program management guide, and ?id=2 redirects there. The other ids redirect to this page, because their subjects are not recoverable.

The id 9 link carries newsletter tracking parameters (m=nw_tu_20111124, a tutorial newsletter dated 24 November 2011), which tells us the tutorials were promoted by email to the magazine's list in the same way the issues were. The Eclipse Testing Day media partnership and the publisher's own agile testing conference in Berlin (the anchor 'Berlin on June 4-5' on the homepage) belong to the same events-and-training side of the business.

The phrase knowledge transfer describes a particular kind of course: a practitioner with deep experience of one subject (program management across several agile teams, say, or test process improvement) teaches a small group over one or two days, with exercises drawn from the participants' own projects, so that the knowledge transfers rather than being presented. It is worth keeping the idea even though the catalogue is gone, because most test teams still learn by sending one person to a conference and hoping.

A knowledge-transfer session a test lead can run in-house has five parts. Pick one subject narrow enough to finish (writing a risk-based test plan for the next release, not 'test management'). Choose the teacher for experience, not seniority. Insist that every exercise uses the team's real artefacts: the actual backlog, the actual defect list, the actual pipeline. Set an output the team leaves with (a plan, a checklist, a decision). Schedule a 30-minute follow-up two weeks later to see what stuck. Two half-days beats one full day; people retain more when they sleep in between.

For subjects to teach, the guides on this site are written so that each can be the reading for a session: the test plan guide has a template table, exploratory testing has charter templates and a session structure, risk-based testing has a scoring matrix. Use them as the pre-reading, then spend the session applying them to your own product.

A one-day agenda that transfers. 09:00 to 09:30, the problem statement: the teacher states the one decision the day will produce (for a risk-based test plan: which of the next release's features get deep testing and which get a smoke test). 09:30 to 10:30, the method in 30 minutes and questions in 30, with the pre-reading as the reference rather than slides. 10:45 to 12:30, the first exercise on the team's own artefacts: score the real backlog with the 5 by 5 matrix from the risk-based testing guide, in pairs, with the teacher walking the room. 13:30 to 15:00, the second exercise: allocate effort by risk class using the guide's table and argue over the two features that consume half the effort. 15:15 to 16:15, write the output: a one-page section that goes into the real test plan on Monday. 16:15 to 16:45, the follow-up contract: who checks in two weeks, and against what. Two half-days on consecutive mornings hold the same content with better retention.

Choosing the subject and the teacher. A subject qualifies if it can be finished in a day and produces an artefact. Risk-based test planning, writing charters for exploratory sessions, scoring automation candidates and writing a layered definition of done all qualify; 'test management' and 'agile testing' do not. The teacher should be the person who has done the thing on a real project most recently, which is often not the most senior person present. A tutor from outside is worth paying for when nobody inside has done it; the original catalogue existed for that case, and the one tutorial the surviving links identify by title, Agile Program Management, is a subject where experience is scarce inside most test teams. The agile program management guide that continues it opens with a figure of one program backlog feeding four teams and a table dividing responsibilities between team level and program level, which is a usable pre-reading for that session.

Measuring whether it transferred. Three checks, two weeks later. Did the artefact leave the room and enter the real process (is the risk scoring in the actual plan; are the charters in the actual session log)? Can a participant who was not the presenter explain the method to a colleague in five minutes? Has the team made one decision differently because of it? If the answer to the first is no, the session was a presentation whatever it was called, and the next one should start with the artefact and work backwards. Keep the count: sessions run, artefacts adopted, decisions changed. Three sessions a year with two artefacts adopted is a better training record than twelve conference days with none.