Trade in your efficiencyTrade some of your existing efficiency in for greater effectiveness instead.
“How can we increase efficiency on our software development team?”
What a common question!
Unfortunately, it’s virtually always the wrong question.
And here’s why:
When we focus on improving efficiency, we tend to focus on things like:
- How can we improve developer utilization?
- How can we reduce the amount of time spent doing non-productive things (like meetings)?
- How can we get more output from the team in the same amount of time?
- How can we reduce the frequency of repititive tasks?
And each of these may seem reasonable on the surface, but each one is subtly wrong for software development.
- High utilization is the enemy of high throughput. Keeping your developers busy 100% of the time means they’ll always be behind. A highway at full capacity is a parking lot.
- Doing “non-productive” things is how (good) software is created. They don’t pay you to type. They pay you to solve problems. This requires thinking time. It requires discussion. It requires a lot of time away from the keyboard.
- More output is meaningless if that output isn’t valuable. Don’t aim for more output. Aim for better outcomes. Software is like surgery. You want the least necessary to get the job done.
- Reducing the frequency of repetitive tasks, such as testing, or deploying your software, may sound nice. But it’s incredibly dangerous. Delaying these processes increases the changes of failure, and the necessity for rework. If it hurts, do it more!
So let’s stop worrying about efficiency. Trade some of your existing efficiency in for greater effectiveness instead.
Effectiveness vs Efficiency
Would you rather deliver 10 stories at the end of the week, or one every day?
How do you keep Devs, QAs and Testers constantly busy?
I understand where this question comes from. But it's the wrong question.