Once, after Seattle Lean Coffee, I had a conversation with a fellow participant about how my team started pair programming. First, I admitted that my entire team doesn’t pair program. My small teams (or pods, as we call them) self organize and function along team agreements they take part in making. But, if I thought it would be advantageous for my teams to attempt pair programming, there are ways that I could communicate and work with them to get them to try it out.
The “No thank you bite”
If there are any other parents out there reading this, you likely already know what this means. I definitely see a parallel between trying to get a team to try something that can make them a healthier team and me trying to get my kids to eat foods that will make them healthier kids. For my kids, we use the concept of a “no thank you bite.” At home, my children are allowed, most of the time at least, to leave vegetables on their plate as long as they have eaten at least one bite of each one. If they like it, they can obviously keep eating more.
Remember though, all rules can be gamed. We are keenly aware that there is a difference between a nice, healthy sized bite and a nibble so small it was nearly non-existent. This concept carries over as well. We expect to see an actual attempt to get the value before you can discard the option.
Isn’t this a little condescending?
The terminology is, yes. Don’t go to your team and say “Now, everyone has to take a no thank you bite of this pair programming before you can say no!” The metaphor is aimed at helping us see the value of getting reluctant teams to experiment with things that might make them healthier teams. Not only that, but to develop a habit or culture of experimentation.
Developers are happy to do this with code — we call these proofs-of-concept or POCs. But, fewer teams do POCs with process or workflow. Sometimes there is a little push needed to get started. Hopefully this comes from within the team, ones that will be in the experiments. However, if not, a manager (like myself) should work with the team to get started on their first process POC – ideally without the blunt force trauma of the application of heavy positional power.
Think like a scientist and hypothesize
Its important that you think your experiment through before you dive in. You’ll be much more prepared to successfully run your experiment and much better equipped to process the findings. Here’s a very simplified & minimalistic view of what you need to do:
Create a hypothesis
There is no experiment without a hypothesis! Meaning, you want to have an expectation that action X will cause result Y and your experiment should be designed to prove or disprove that expectation.
Understand your variables
When you get findings to analyze, you want to be able to be sure they’re meaningful and that you understand other variables that could affect the outcome.
Your experiment should have a beginning and end. At some point you need to analyze the results.
There’s no point in doing an experiment if you never analyze the findings. This is the moment you’ve been waiting for. Determining if your hypothesis was correct. Compare what you thought would happen versus what did happen. If it failed, by how much did it fail and why? Does something just need a tweak and then it would be awesome? Was it a colossal disaster? Was it perfect?
Use the information discovered in your analysis to design the next experiment. Remember we’re after a culture of experimentation here.
In the end, we’re committed to being a healthy team and we should be agnostic in regards to which process is the best one to get us there. No [metaphorical] sacred cows here! Its fine if your plate of vegetables needs to look like this for success…