Modern software development is as much about people and relationships as it is about programming languages and tools. A single developer, no matter how good, is never going to be as effective as a highly performing team. Over years working in such environments I have built up a rudimental understanding of the psychology behind teams, good and bad.
People like to work within a framework of beliefs. We use this framework to make decisions about what is right and what is wrong, to predict what will work and what won’t. We favour information that confirms our beliefs and discount information that doesn’t. The difficulty is that everyone will have a different set of beliefs. When we are confronted by opposition the natural instinct is to assume that you are right and the others are wrong. People don’t like to think they are wrong, and so filter out information that does not confirm their pre-existing beliefs. This is confirmation bias.
It is possible for people to change their beliefs but there needs to be a reason. Usually it is down to self-preservation. If there is an obvious benefit to change, they will change. It is just a case of finding the right motivation.
This sums up confirmation bias for me
The probability of one person adopting a belief is proportional to the number of people who currently hold that belief. Ever feel like you are swimming against the current, when everyone is against you and you’re the only person talking sense. This is the bandwagon effect.
The bandwagon effect is why it is hard to argue your point in a group of three when the two others hold the same opposing views. It is also why you can influence the direction of a team by ensuring that you have a core set of people who share your beliefs.
This is the assumption that the more information you have; the better decisions you will make. This is not always the case because information can be contradictory or bring its own bias to the table. Often people can make acceptable decisions with a lot less information. It is usually better to make a decision using the information you have, rather than deferring it.
People who suffer from information bias can struggle in Agile environments. Generally, user stories are brief and are likely to be missing “all” the information. Analysis paralysis ensues as the team strives to obtain a complete picture. Successful Agile projects tell us that all the information is not required, or at least it is not all required up front. A successful outcome is achieved through feedback and collaboration, experimentation and testing rather than amassing all available information at the start.
Many of us are so confident in our abilities we will make commitments on behalf of ourselves and our teams without assessing the risks. Often it is the experts that are the over confident people as they are convinced they are right. How many times has an expert in your project under estimated the complexity of a feature, made a commitment and then the whole team finds itself under pressure.
Sunken costs fallacy and the impact on Agile teams
A sunk cost is any past cost that has already been paid and cannot be recovered. In IT this may be the time (and therefore resource costs) of gathering requirements, or doing an architectural study or refining a design. This time and effort is gone and cannot be recovered.
However, many people look at this differently. “It cost 20% of the project budget coming up with the design so we need to implement it otherwise we’d have wasted our money”. Did anyone stop to think if the design was appropriate or whether the requirements had changed or whether the product was even needed anymore.
Upfront planning is a common cause of sunk costs. The longer and costlier the planning phase, the more temptation to see it through. Agile projects go some way to address this by doing regular planning and therefore minimising the perceived costs lost if the direction of the project changes.
In large scale Agile projects, you may have a team of people working a sprint ahead, getting stories ready for the next sprint. This team will be fleshing out the details of stories, decomposing them, working out dependencies and even defining the order in which they need to be delivered. This looks good on paper but in this model without the SCRUM team’s involvement not much of the planning will remain intact when they do get involved. Sunken costs come into play because the “design team” are reluctant to throw away all that effort. The SCRUM team then become disengaged because they are simply implementing someone else’s design. All the Agility you have tried hard to gain is lost.