July 30, 2016
Stop Being a Cave Dweller
—Challenge new information especially if it's based upon opinion and speculation.
In Whispers and Cries Mark Bernstein
discusses the dangers of misinformation and how blindly accepting information--the unwillingness to challenge the status quo leads to problems. I share my experience with misinformation in Product Backlogs: Not Just Stories!
when I explored statements made by Bertrand Meyer on user stories and Agile practices. Because of that exploration I corrected an error in my thinking on Scrum.
The insight Mark provides is to build a better network for your questions and to allow yourself to make mistakes. He points out that most software developers work in caves or enclaves. Those in caves use the tools and techniques they already know and only acquire new knowledge as required by circumstance. Those in enclaves use commonly accepted practices within those enclaves and that wisdom-formation in enclaves is often erratic.
What prompted Mark's article appears to be a discussion in The Dangers of Misinformation
. There is advice in that article on how to share information and avoid spreading misinformation.
The situation in Mark's article and the one he references both identify a form of bias. Misinformation, when accepted by an enclave or by large numbers of people is a form of social proof. I suspect that those of us working in caves suffer from social loafing.
The error identified in my thinking on Scrum was introduced through social proof: when I learned Scrum the people teaching me insisted on user stories to manage my product backlog. I asked for and obtained references. Those references reenforced the use of user stories and I accepted it as correct.
Fortunately, there were problems in our implementation of Scrum. These problems prompted me to do my own research. That research led me to the Scrum Guide. Unfortunately, my review of the Scrum Guide didn't reveal my error in thinking on user stories.
Fortunately, I enjoy Bertrand Meyer's work so I purchased "Agile! The Good, the Hype and the Ugly". Ironically, it wasn't his position on user stories that identified my error. It was his position on how user stories were inadequate for some types of systems that caused me to delve deeper.
I had been troubled by user stories when I first encountered them. As I gained experience with them, nothing pointed to any inadequacy. They were just new and different. Meyer's comments on additive and multiplicative complexity caused me to review why user stories had worked for me. It was that investigation that led to the realization that I had misunderstood how to populate the product backlog.
My misunderstanding about user stories and Scrum lasted four years. During that time my defences against social proof failed because the biases of the people teaching me Scrum and their own research reenforced what I was taught. My own experience with user stories only confirmed these biases and further entrenched these ideas.
Doing your own research is important and that using original sources for that research is critical. In exploring Meyer's position on user stories I reviewed both the OOPSLA 95 paper that introduced Scrum to the work and the Scrum Guide to confirm part of what Meyer's said about user stories.
The only activities that led to identifying my error was my desire to learn more about Agile methods. Meyer's work provides an invaluable resource simply because of its contrarian views--whether you agree with them or not. In my case, the urge to explore and understand why he reach conclusions that contradicted my own experience were critical to my new position on user stories and the product backlog.