XP - J. B. Rainsberger's Greatest Misses
Tuesday afternoon was polished off with the intriguingly titled 'XP: My Greatest Misses 2000-2008'. Presented by J. B. Rainsberger, the founder of XPDay North America, it documented some of what he considered to have been his biggest mistakes since his conversion to the XP camp in 2000.
He came to XP while working at IBM, in an attempt to avoid defect ping-pong with the testers. After discovering XP he became an instant and enthusiastic convert, literally yelling its praises in the hallways. Finding he had failed to convert any of his colleagues he instead adopted a stealth strategy - demonstrating the qualities of the methodology by the quality of his work, confident that his continually low defect count would win him enquiries as to his methods. Instead, he found he left people pissed off, feeling they had been shown up by this upstart. So he tried a third method - proposing himself as a coach, only to find that his credibility was shot and that without credibility there are few who will listen.
However, help was soon at hand in the form of Toyota, who were starting the first XP project in Toronto. With a plan of building a base from which to expand to other engagements J. B. and his cohorts spent a lot of time massaging data and ensuring that their numbers were the best possible. Unfortunately, they found velocity was not a speedometer, and the impressive numbers did not equate to software. Management soon imposed their will and a quick exit was effected upon the cancellation of pair programming.
Later, he found a great opportunity to learn to teach when offered a role as a tutor for Java topics. Not having the emotional investment left him free to concentrate on learning to teach, rather than on the topic being taught. Eventually leaving to start work on a book, he began consulting, with the intent of whipping developers into shape and letting the agile concepts flow outwards into the organisation. On his first attempt he found a receptive team and started them anew with the aim of getting something that could be run in short order. However, velocity was low and so the stories were split into ever smaller segments. This continued under a BA estimated the number of stories required to complete the software at a notable 12000. As results had failed to materialise he had focused on a single problem, leaving the bigger picture at risk, saved only by this timely intervention.
Later he found himself in a similar engagement, introducing a team to agile, only to find that while some members of the team were enthusiastic in their engagement others insisted on withdrawal, marking out their personal space and avoiding communication with the team. Further, each team was being subjected to multiple trainers, each with an individual approach and style, and yet none thought to ask the team - what;s going on, what sucks? In this case an emergency retrospective let the discussion flow and sorted the problem, but without a view of what's going on within the team you're likely doomed.
He then briefly addressed motivation. People are motivated to do something to the extent they believe they can do it; to the point they can see the consequence of doing it and where they wish those consequences to occur. Where you have motivation problems, these three principles are a great place to start.
He finished with a flash of insight: while waiting for a flight in the barren wastes of Pearson airport he had a flash of insight, suddenly realising he had screwed up every previous agile engagement. Immediately he put pen to paper and wrote an open letter of apology, later published as the Last Word in Better Software Magazine. At the end of the day, it's not technical skills that make the difference but people skills.