The New Economics

I’ll start with the disclaimer that when I came across the SoPK, I had no one to discuss it with or learn from. What I’m describing here is how I interpreted it at the time shortly after joining the QA team in 2018. A few months ago I read the The New Economics and met others who have shared their wealth of knowledge. I’ll probably re-visit this later in the year after I re-read The New Economics.

  1. Appreciation for a system I’ve tried to cover this in What led me to a QA team?. Basically my dev team and the QA team were always competing for project time. Each wanted to maximise the time we could spend in our local silos to do a better job. I realised that there had to be better collaboration so that we’d optimise globally. The testers were working as hard as the developers in my team but the very way we were working was resulting in neither of us being able to do our best.

  2. Knowledge about variation I saw most of the variation (defects) as common causes. I explained more in the analogy of the Tree Swing that by working in silos, trying to capture our mental model of the customer’s requirements in the form of code or test data, the longer we didn’t sync up, the higher the probability of there being more variation. The smaller the batch sizes coupled with test automation etc, the lower the variation. It’s something that eventually happened with the COBOL developers and testers. By being able to write test and code for the next small chunk of functionality, they didn’t deviate very far from the shared understanding.

  3. Theory of knowledge To me this was the scientific method and the PDSA. My team could agree or disagree with me, I didn’t care about either. What I cared about is how they came to the conclusion; how did they know what they thought they knew. Previously I’d hear testers ask, “Why can’t developers do a better job unit-testing”. I was really happy when the day came and one of the senior testers realised that the cause of the developer defects was because of the system of how they worked. He then asked if it was possible to actually test earlier with the developers. Eventually they realised that even if they did, we’d still have defects. Previously they thought they knew what would make them efficient but eventually through a whole bunch of PDSA, they found that it wasn’t true.

  4. Psychology As I mentioned elsewhere, for this I relied only on Simon Sinek’s work. I found no other resource. The approach he described in this presentation is basically how I moved the team forward. I had to find a way to make my testers and the developers want the change. Using the carrot and stick approach couldn’t work. There wasn’t enough money in the budget to give big raises. People were already burning the candles at both ends so fear wouldn’t work. While I didn’t introduce more things to be fearful about, I did re-use the fear of them losing their jobs. I had told them that if they were going to lose their jobs, wouldn’t it be better if they did so with all the new skills I would teach them than not? Over time they saw nobody lost their jobs, they just got to finish work on time and more people opted-in to the transformation.