If something is painful, should you do more of it? Not if it’s painful because you have the wrong tool.
Sometimes though, it doesn’t matter what the tool is, there’s something more fundamental at play. A process that exists only because one thing went slightly wrong years ago. And rather than implementing a process to correct mistakes, somebody tried to prevent them.
Just like technical debt, this process debt adds pain to every feature, every bug fix, or every release. That pain can be removed by removing the process.
It’s painful because you shouldn’t be doing it
Does your test plan or your requirements sheet still specify IE as a supported browser? If Microsoft doesn’t support it why should you?
Are you spending all your time monitoring your staff, making sure they’re working when they’re not in the office? Do you struggle getting the right reports? Do you feel resentment from your staff even though it’s in their best interest? Or have you tried trusting them?
Is every release delayed because the database team and the security team have to review all code, and they’re already overstretched? Have you asked them how to provide confidence with less manual intervention? How to minimise the impact any change could make? How to add automation for common areas? How to train the developers to fix common issues upstream before it gets to the frontline teams?
Have you ever thought about deleting a process that isn’t adding anything? About making things simpler?
`The Untapped science of less : Inquiring Minds podcast’
Craig Nicol 