I got a few questions about org dysfunction and how it specially relates to software testing, so I figured it would be easier to address them here as sort of a “reply all” to the different channels where I’ve made those comments.
Merriam-Webster defines “dysfunction” as: 1: impaired or abnormal functioning or 2: abnormal or unhealthy interpersonal behavior or interaction within a group. In my experience, organizational dysfunction occurs when leadership have misperceptions about how the organization is designed and actually operates, but more fundamentally, not understanding that the organization is performing EXACTLY as designed.
There are LOADS of different types root causes of organizational dysfunction and just as many root causes. For further reading on org dysfunction an how metrics/management contribute, I would highly suggest Measuring and Managing Performance in Organizations by Robert Austin. But these are the ones I consistently see affecting quality and software testing and further displacing the goals of your teams and company.
1. Competing objectives between teams.
A common practice I see in organizations I consult with are incentivizing teams with competing objectives, specially rewarding feature delivery, code deploys, and defect counts. If you are targeting, measuring, and compensating people in a way that is not harmonized around common goals, you are sure experience silos, information hoarding, and “green shifting” or subconsciously (or in some cases not so much) viewing things better than they are.
2. Failure to adopt new practices.
This is very common in organizations that don’t value innovation as they are only rewarded for ideas that originate with management. People often wonder if I am exaggerating some of the stories I tell about large, global technology teams that seem stuck in 20-30 year old ways of doing things. I assure you I am not, and as well, survivorship bias has a strong hold on a lot of teams that won’t view change as anything other than a threat to personal status and privilege.
3. Heavy process and standards.
Aside from mostly perpetuating the mythology around audits and compliance, organizations that apply heavy handed process and standards typically suffer from the worst cases of CYA. When you don’t trust your people to be responsible for their work, they will resort to making sure their worlds are clearly defined and problems can start to be admired instead of solved.
“I know it sounds like a cat poster…..but it’s true”
I did a talk a while ago about how org dysfunction effects software testing called “All Your QA is Hate You: Software Quality Anti-Patterns in Testing”, so I won’t go into them in great detail here. But if you are trying to do the following things: shift left, centralized testing, decentralize testing, view testing as a “role”, then your process improvement efforts will probably fall under “Sturgeons Law”.
Theodore Sturgeon’s was an American writer who famously coined “Sturgeon’s law”, which states that ninety percent of everything is crap. The reasons most tester led TPI doesn’t break the law, is because testers themselves usually aren’t business focused, are technically obsessed, and don’t study their craft making them easy marks for vendor schemes and marketing.
My simple advice to combat the effects of org dysfunction are to look for ways to further align you test strategy to your business strategy, manage risk, not testing (threats to revenue, realization of business value), and believe it can get better!