The goal shouldn’t be to have BDD or CICD, they’ll come about gradually, it’s to create a culture of continuous improvement and easy ownership. As my QA team culture changed, they and the COBOL developers learnt that the QA team’s tests driving the developers code changes was the better way of working. The second order effect was that people saw there was no need to rely on inspection at the end to ensure quality. All of the work done by both teams was done with no restructuring of the teams, no budget for the training and no delays to the release schedule, just hundreds of kaizen after 4.5 years.

The opposite is telling everyone we’re doing BDD. They’ll go online and read about a tool called Cucumber with a programming language called Java. The testers will say they can’t code and so might everyone else. The developers will say they can code but only in COBOL. My transformation would have died right there.

Another reason for taking the buzzword free approach is because there were so many. I wanted to make sure I wasn’t so biased in blindly believing that Continous Delivery or BDD was the best way to go. So I decided I’d just study the variation, identify common cause ones and do PDCA. I wanted to see what process and practice emerge if we systematically and scientifically removed bottlenecks, constraints and wastes.

  1. Coach Teams Not Individuals
  2. Start With Why
  3. Gravity Slingshot
  4. Culture of Easy Ownership
  5. The Neo Nurture Incubator
  6. The Power of Habit
  7. Diffusion of Innovation
  8. Shu Ha Ri