AgileNZ - Towards Mastery: Establishing Craftsmanship Culture in a Team

“We need software developers who are professionals and view their work as a craft!”. This is often heard in development teams as a reaction to fragile systems built on messy codebases. This statement also often implies a yearning for a certain type of developer… those (lucky ones) who go home and hack until the early hours of the morning to pursue their thirst for knowledge.

In reality, many developers don’t have the time to build their skills and some others see their job as something confined to 9 to 5. This is ok, but it results in teams that don’t grow which exacerbates the problem where companies rely more and more on ‘ninjas’ and ‘rock stars’. This has to stop! We need an alternative. Let’s build our people within their constraints and let’s figure out how to do it well!

This talk explores techniques that the speaker has successfully applied to help many companies and teams improve the quality and effectiveness of their engineering efforts: creating a culture of learning with techniques such as code dojos, katas and other intentional learning activities. Helping developers learn and apply practices such as clean code, refactoring, TDD, pair- and mob programming and continuous integration. Overcoming common arguments against intentional learning and improvement.

Transcript

1. @martincronje Establishing a craftsmanship culture in a team Martin Cronjé Development Manager - MYOB @martincronje martin.cronje@myob.com
2. @martincronje Who are you?
3. @martincronje .01 WHY IS THIS IMPORTANT?
4. @martincronje Skills shortage
5. @martincronje We live in exponential times
6. @martincronje 47% jobs have a high chance of being computerised by 2023 From: The Future of Employment: How Susceptible are Jobs to Computerisation
7. @martincronje Number of software developers are doubling every 5 years From: StackOverflow Developer Survey
8. @martincronje Most systems are in disrepair 312 Billion USD spend debugging of which 52% are spend on Architectural defects – Deloitte research on Tech Debt reversal
9. @martincronje Discussion: Why do teams struggle with keeping systems clean?
10. @martincronje People are our greatest asset
11. @martincronje
12. @martincronje 3,768 pages
13. @martincronje Reading non-stop, how long does it take you to read a 300 page book? Poll on goodreads.com (6342 responses) 2.40% 17.3% 36.8% 21.5% 10.0% 12.0% An hour or less 1-3 hours 3-6 hours 6-9 hours 9-12 hours More than 12 hours
14. @martincronje Discussion: How do we help teams acquire this knowledge?
15. @martincronje Problem #1 People have lives
16. @martincronje Problem #2 No opportunity to apply it
17. @martincronje /takeaway WE NEED TO GROW PEOPLE @martincronje martin.cronje@myob.com
18. @martincronje .02 WHAT CAN WE DO ABOUT IT?
19. @martincronje Learning about learning
20. @martincronje CodeRetreat
21. @martincronje • Day long event with 5-6 seperate 45 min sessions. • Attempt to implement Conway’s Game of Life in each session. • Do not have to complete anything. Delete code every sessions • Different pairs per session with people you don’t normally work with. • Get out of your comfort zone. Experiment and learn. Try different paradigms. Deliberate Practice: Coderetreat
22. @martincronje Code Katas and more
23. @martincronje • Direct application of the principles on deliberate practice. • Started as simple coding exercise focused on learning specific skill from TDD to Refactoring and Emergent Design. • Architecture, analysis and design katas have also been developed. Deliberate Practice: Katas
24. @martincronje Coder Dojos
25. @martincronje • 1-3 hours session with retro every 45 minutes. • Work on any kata that the group thinks is relevant for them. • Repeat katas over numerous sessions. • Done using Mob Programming with 4-7 min turns at the keyboard. • Use strong pairing technique. • Run a retro at the end. Deliberate Practice: Coder Dojos
26. @martincronje Learning by doing
27. @martincronje “…Activities designed, typically by a teacher, for the sole purpose of effectively improving specific aspects of an individual’s performance…” K. Anders Ericsson, Psychologist
28. @martincronje • Target specific skill • Repeated a lot Deliberate Practice • Continuous feedback • Must be hard
29. @martincronje /takeaway PRACTICE PRACTICE PRACTICE @martincronje martin.cronje@myob.com
30. @martincronje .03 HOW DO WE MAKE IT WORK?
31. @martincronje Discussion: How will you apply this in your company?
32. @martincronje As a coach
33. @martincronje
34. @martincronje CLIENTS COLLABORATE SIMPLIFY INNOVATE RESULTS PASSION MYOB’S VALUES DRIVE OUR WORLD WE’RE BETTER TOGETHER MAKE IT EASIER FIND NEW WAYS ACHIEVE OUR GOALS LOVE YOUR WORK
35. @martincronje CLIENTS SIMPLIFY INNOVATE RESULTS DRIVE OUR WORLD MAKE IT EASIER FIND NEW WAYS ACHIEVE OUR GOALS COLLABORATE PASSION MYOB’S VALUES WE’RE BETTER TOGETHER LOVE YOUR WORK
36. @martincronje
37. @martincronje • photo
38. @martincronje Feedback… • Working across teams • Knowing what I don’t know • Trying out different techniques • Variety is great • Collaborating for the first time
39. @martincronje • Deliberate practice principles as a baseline. • Work in groups to encourage shared learning • Single objective for exercise • Known tech if we are learning a new practice • Focus on areas where we need to grow • Be open to try things radically different Making it work Principles Execution Logistics
40. @martincronje Logistics • Everyone from the team involved • 3 hours every Friday afternoon after retrospectives and showcases • No work normal production work unless there is a production outage • If coding session, Everyone should already have a working environment with test-runner in their desired platform Principles Execution Making it work
41. @martincronje • Remind everyone of the principles. • Remind team of the outcomes from the previous dojo and get input for current day. • Set constraints for the day such as exercise, coding session length, platform, pair vs. mobs. • Run coding sessions and end each with a quick retro. (30, 45 or 60 minutes) Execution Logistics Principles Making it work
42. @martincronje /takeaway CREATE SPACE FOR LEARNING @martincronje martin.cronje@myob.com
43. @martincronje .04 MAKING IT LAST
44. @martincronje Then things became shaky
45. @martincronje • Learning new things • Having fun What worked… • Collaborating as a team
46. @martincronje • Different learning styles • Different needs per team • BA’s and QA’s excluded • Practices vs. Technologies What didn’t work
47. @martincronje Different needs and styles
48. @martincronje What worked for BA’s and QA’s
49. @martincronje Practices vs Technologies
50. @martincronje Practices vs. technologies
51. @martincronje /takeaway KEEP ON EXPERIMENTING @martincronje martin.cronje@myob.com
52. @martincronje Tips for the road
53. @martincronje .05 TIPS FOR THE ROAD
54. @martincronje Tips for the road: Getting buy-in Growth: • Software will be able to do 25% of job within 10 years* • Number of developers are doubling every 5 years ** Hiring: • Hiring developers who learn on their own time is not sustainable. Their personal conditions change and the hiring pool is limited. • Hiring the best developers is become an arms race of who has the best offices, salaries, work. * The Future of Employment: How Susceptible are Jobs to Computerisation ** StackOverflow 2016 Developer Survey ** http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
55. @martincronje Tips for the road: Sustainability • Same place, same time every week as with retrospectives and stand-up. • Teams may not see value initially, give it a month or two. • One stabilised start coaching others to run the sessions. • Practices the katas with a smaller group ahead of the time to get an idea on what they are about.
56. @martincronje Tips for the road: Production Code TDD and emergent design: • Create a kata out of a recent story and experiment on a detached branch Refactoring: • Use scratch pad refactoring to experiment with different ideas on detached branch. • Take the best most recent code created by the team and refactor it. • Also take the oldest messiest code.
57. @martincronje Tips for the road: Inventory Test-driven design • https://en.wikipedia.org/wiki/Conway's_G ame_of_Life • http://codekata.com Emergent Design • http://codekata.com (Checkout Kata) Refactoring • https://github.com/jbrains/trivia • https://github.com/emilybache (Especially Gilded Rose) Architecture • https://archkatas.herokuapp.com Story Mapping • https://archkatas.herokuapp.com
58. @martincronje .01 .02 .03 .04 WE MUST INVEST IN OUR PEOPLE PRACTICE MAKES PERFECT KEEP ON EXPERIMENTING CREATE SPACE FOR GROWTH
59. @martincronje Thanks for listening Any Questions? @martincronje martin.cronje@myob.com