Teaching New Tricks

Originally delivered at Agile Manchester 2017 (http://agilemanchester.net/2017/sessions/index.php?session=39).

As part of my job as an agile consultant, I spend a lot of time introducing and reinforcing software development techniques to experienced developers from a wide variety of backgrounds. This means extolling the virtues of TDD and pair programming to people who have never even heard of it, as well as contractors who have worked on several projects that flew the 'agile' banner but left them with the impression that techniques such as TDD are cumbersome and pointless - and people with many levels of experience between the two.

The techniques being introduced or reinforced are many and varied: kanban boards, daily stand-ups, retrospectives, kick-offs, desk checks, continuous integration and deployment, TDD, pairing, and so on.

Many of us have learnt these techniques gradually, both on the job and off. As with any skill, it's easy to forget what it felt like when you were a beginner. It's also easy to get stuck in routines and forget why you decided to use a method in the first place. It's just as easy to find yourself applying something simply because that's what you've been told to do, with no clear evidence that it works.

This session is a description of the challenges involved in helping a team of experienced devs to become a self-organising agile team, with a bunch of new skills and the will to keep things going on their own. It will include several practical suggestions of how to help and convince less agile-experienced colleagues, as well as a discussion of limitations and how to avoid and mitigate the pitfall of exaggerated expectation.

Transcript

1. Teaching New Tricks @claresudbery
2. The Old Dog
3. Empathy
4. The Specialist
5. The Cynic The Cynic
6. The Expert (…who disappears)
7. The Unengaged
8. The Pattern Cutter
9. The Newbie
10. The Wary Pair
11. Keyboard Hogging Keyboard Hogging
12. Follow my Leader
13. The Intrusive Pair
14. The Pair at War
15. The Comfortable Pair
16. The Reluctant Pair
17. Give Evidence
18. Evidence • Pair Programming – The Most Extreme XP Practice? http://www.davefarley.net/?p=214 • - Nawrocki/Wojciechowski, 2001 – “Experimental Evaluation of Pair Programming”-- https://www.researchgate.net/publication/2531047_Experimental_Evaluation_of_Pair_Pro gramming • - Cockburn/Williams, 2001 – “The costs and benefits of pair programming” -- http://dl.acm.org/citation.cfm?id=377531 • Good general reading – “So how good is pair programming, really?” by Rickard Dahlstrom -- https://raygun.com/blog/2015/11/how-good-is-pair-programming-really/ • Shorter reading, good for mgmt -- "Pair Programming Benefits - Two Heads Are Better than One" by Jeff Langr, Tim Ottinger-- https://pragprog.com/magazines/2011-07/pair- programming-benefits • Old but still solid research -- Strengthening the Case for Pair Programming" by Williams, Kessler, Cunningham, Jeffries -- http://dl.acm.org/citation.cfm?id=626149 • Mini-book – “Pair Programming” by Naresh Jain -- http://www.slideshare.net/nashjain/pair-programming • ‘The Case for Collaborative Programming’ Nosek 1998 • ‘Strengthening The Case for Pair Programming’ Williams, Kessler, Cunningham & Jeffries 2000 • ‘Pair Programming is about Business Continuity‘ Dave Hounslow
19. Empathy
20. The Workshop
21. Group Learning
22. The Discussion
23. Teach by Example
24. All the brilliant minds…
25. Use the Mob
26. Knowledge Sharing
27. Learn by Teaching
28. Lunch and Learn
29. Spreading the Word
30. Ask Questions
31. Empathy
32. Explore
33. Deep Dive
34. Innovate
35. Highlight Good Examples
36. Don’t Overload
37. Safety and Security
38. Connect
39. No Elitism
40. No Arrogance
41. No Exaggeration
43. Nobody Knows Everything (not even you)
44. Be Open to Change
45. Empathy
46. The Happy Pair The Happy Pair
47. The Converted
48. The Re- energised
49. The Reheated
50. The Reassured
51. (The Tories and their austerity measures are ruining education, by the way) Education
52. The leftover pics