Make the problems painfulAvoiding pain often prevents us from improving something important.
We naturally avoid pain. Obviously.
But sometimes this means we don’t address problems.
I’m not a big fan of running. I find it hurts my feet, and after just a few moments I’ll be out of breath. But of course, it would probably do wonders for me if I would run just a bit. But of course, I don’t run. Because it hurts. It’s stressful. It’s not fun.
I see the same sorts of behaviors all the time in software development. The best developers, after all, are the laziest, always seeking ways to make their own jobs easier.
This becomes a problem when it prevents us from improving something important. Perhaps my weight and overall health with respect to running. Perhaps delivery time, and defect rate, with respect to software delivery.
When I’m teaching teams to transition to continuous delivery using Lean CD, often one of the first bottlenecks that’s discovered is contention on a pre-merge shared testing environment. A common reaction to this felt pain is “let’s go back to the old way of working” (which usually means post-merge manual testing).
Such a reaction may aleviate some of the immediate felt pain, but the pain in this case is a good thing. It points us to where we need to improve.
If it hurts, do it more.
If you’re struggling to solve this pain, I encourage you to join me starting Monday, October 3, for the Lean CD Seminar. I’ll help you work through that pain, rather than avoiding it. Or your money back!
What's the ideal ratio of devs to QAs?
Of course, as a consultant, I can confidently tell you: It depends!
Which comes first? Manual testing or continuous delivery?
Does not feeling "ready" for CD mean that manual testing is a good alternative? Not really.