Thoughts From Chet Hendrickson’s Talk “What Should We Have Done Different?”

Not long ago, Chet Hendrickson (one of the early eXtreme Programming practitioners along with people like Ron Jeffries, Bob Martin and Kent Beck) gave an online talk/webinar entitles “What Should We Have Done Different” in which he looked back at the early days of Agile work and considered what perhaps could have been done better. He focused on three things:

1. What was originally taught.

2. How they viewed their own work.

3. The size of work.

Regarding the first point:

Chet said “We taught answers instead of how to find answers” and that this “was a disservice.” What he felt should have been done was to teach “a process to try lots of things, not a set of practices,” encouraging people to “experiment to see what works for us/you.” Then, “what works for you is what you should do.” This “may mean learning…, but learning is good.” We also learn “by challenging each other.”

As part of this he pointed out how pairing was a valuable practice since “two brains think faster than one or two separately.” He also emphasized the importance of the “conversion” part of stories, since “the conversation is the ‘story,’ not what you type into Jira which is like a vacation photo: it is a reminder of the vacation.” He closed this point by asking, “Do you know what you’re doing each day?” In this regard, I encourage people, when I coach/train them, to take a few minutes at the end of their day and ask, “How do I know that work I did today was of good quality?” (Later in the talk he said, “Less Jira, more Jenkins.”)

Regarding the second point:

Chet felt that he and his early colleagues “were on the far end of the excellence spectrum, but [they] did not think so, so we thought what we did was what everybody could do.” This may have prevented early examples of how to do what they were able to do. He said, “People may never have seen what ‘really good’ looks like,” so their understanding of how the early XP folks achieved results was not clear. (In this regard, check out this fun video where Chet and Ron Jeffries give a “talk” about their programming practices by actually programming in front of the audience: https://vimeo.com/215226746. He encouraged focusing on two things: building teams more than building products since good teams can then build good products; technical excellence.”

Regarding the third point:

Chet asked that we “think big but build in the smallest way possible.” He quoted GeePaw Hill (Michael Hill) who said, ”Many, many more smaller steps.” You can see this approach in Ron and Chet’s video.

I mentioned a team I knew that felt a lot of time was devoted to story point estimation. What they decided to focus on instead was breaking their stories down into pieces that could be completed (all design, coding, testing and documentation) in 2–3 days at most. Having done that, they assigned 2 points to every story, effectively finessing away estimation in favor of focusing on working in small increments. Chet replied that, “I use Fibonacci but stop at 1.” (People in very large corporate systems work may find it hard to do that. (Mike Cohn, when I mentioned this to him in one of his regular Q&A calls, said using best and worst case estimation when a range of estimate values is likely necessary for those large systems and their estimation/budgeting expectations.)