Agile 2009 Session Info
Presenter: Mary Poppendieck
Mary is well known as a lean software engineering leader, but gave this session talking about the idea of deliberate practice and our field. She referenced studies by Anders Ericsson about what it takes to be truly world class at something (she particularly focused on a juvenile music school example).
The key take away from that research was that genetics was not the critical element; deliberate practice was. Just as Chris Shinkle’s Dreyfuss stuff talks about, it takes around ~10,000 hours of deliberate practice to become a true expert at something.
The concept of craftsmanship in software (which is really what this was about) was a consistent thread among the ‘rock stars’ who spoke at the conference. The current state of industry really is working against this with ineffective project management techniques, lack of respect for the individual, constant job hopping, and lack of mentorship. And yet, craftsmanship is one of the primary solutions to our problems …
Deliberate practice has four elements:
1.A mentor/teacher/coach who knows the skills involved and the exercises needed to improve them
2.Being challenged to improve, frequently … not just doing what you’re already good at
3.Feedback, feedback, feedback … that coach telling you what you’re doing right and wrong
4.The dedication/passion to stick with it
Amongst people who become world class, they are often driven externally early (think children with music or sports), but later feed on the success and the activity becomes its own reward.
As she was explaining all this, I wondered exactly what that meant for us. Is she saying that only professional development done ‘off the clock’ is deliberate practice? She further clarified that the analogy to sports and music was somewhat flawed and that she felt the day to day work we do as developers was in fact deliberate practice – so you can now go back to seeing yourself as an expert. 😉
She went into great detail on the four elements, what it takes, etc. I can’t reproduce all that here, but there were some things that really jumped out at me:
·Teachers are NOT product champions (project leaders in our world) … they are competency leaders. SEP is kicking around some ideas we’re calling ‘practice management’ that can help us in that area, but we’re still in the early stages there.
·Teachers (competency leaders) should: hire and grow people involved in their topic, review and guide work, set company standards, and ensure excellence.
·One thing she said a lot: “If something is difficult, do it more often and it will get easier.” She cited frequent deployment and continuous integrations as examples.
·Regarding challenge, she asked a hell of a question: who in your organization is thinking about what someone’s next assignment should be so that they can continue to grow? Are you consistently trading short term project performance for long term career growth? As I type this, I wonder about the relationship between this and liquidity…
·Getting developers exposure to actual users actually using the products we build is critical. This idea came up a lot throughout the conference. I would love to see more of this, though it can be a challenge in our scenario – our end user is often our customers’ customer.
·She was a big fan of anything that sped up the feedback cycle – continuous integration, pair programming, TDD, etc. She feels that one of the reasons people like working on open source projects is actually the fast (and sometimes violent) feedback. She has also observed that having good feedback mechanisms typically improves companies retention of talent.
·On the dedication topic, she explained the process a design engineer at Toyota goes through. I’ll save you the details, but it’s around 6-7 years before they’re allowed to do anything significant! They have a very strong apprentice-journeyman-master concept. Despite the looooong period of hand holding, their satisfaction and retention rates are exceptional.
·She cited the fact that most companies don’t provide a technical career path. I felt a little pride for a moment, then remembered that we still have a ton of work to do with ours.
·She cited something called Dijkstra’s Challenge, that essentially said “software can’t get better until we inject fewer bugs”. He wrote that over 30 years ago.
·Quality construction should be the goal of all software processes. Measuring percentage of time spent in test and fix may be an effective measure of technical competence.
·The software craftsmanship manifesto. This was new to me, would love to hear what you all think of it.
