When I was in primary school I remember learning about herds of buffalo that were so vast that it would take hours for all of the animals to pass a specific point.  Herding behavior evokes visions of groups acting the same way. There is a special case that affects how work is accomplished. Self-herding affects how decisions are made based on how an initial event is tackled. Dan Ariely defines as  “our tendency to follow the same decisions we have made in the past (future decisions are influenced by previous decisions).” Self-herding is a form of cognitive bias in which an individual creates a heuristic for a specific decision, limiting the possible outcomes.  A classic example of self-herding is the rule many people develop that states that, all things being equal, given two restaurants the one with people is better. The origin of the rule many times in unknown and doesn’t get questioned. I believe I originally heard this guidance from my mother.  Even today I have difficulty going into restaurants that are empty. The first time I used my mother’s guidance the decisions translated into behavior that I rarely question even today. Restaurants might be one thing, but a decision about accepting work or using a specific framework should be a different matter but the answer is no. 

Susan Parente, Software Process and Measurement Cast columnist, choose the name of her column, “Not a Scrumdamentalist” to highlight the propensity for software teams to use the rules of Scrum to self-herd at the expense of context. The initial decision coupled with positive feedback creates a bias to always use Scrum the same way for each piece of work. The heuristic based on the initial decision works until it doesn’t. Saying “yes” to work as it shows up is often a self-herding behavior generated from an initial decision that was well received. 

When groups herd for safety or to generate positive outcomes for a leader or team we view this as rational economic behavior. Self-herding does not represent rational behavior because it codifies in a decision-making heuristic. Jon Quigley told me a story recently of a project manager that vehemently felt that is was never ok to say no. Our codification of the rule was based on the time value of pain, pain in the future is always preferable to pain today.  Saying yes today avoids the immediacy of hard conversations and postpones them to an uncertain time in the future that may never come. The problem with this type of self-herd is that as a leader when the pain of a missed date or poor quality comes (and it always does), everyone on the team gets to share, and we all know that misery loves company.