19 October 2026 · Dean Hume
Deliberate Practice and Continuous Improvement in Software Teams
Have you ever done something for years and still felt like you weren’t getting any better at it?
I’ve been reading Grit by Angela Duckworth recently and really enjoying it. One idea in particular has stuck with me - deliberate practice.
You’ve probably heard the claim that it takes around 10,000 hours to become an expert at something. It’s a neat idea, but it raises an obvious question. Say you’ve been out for a run every other day for the last 10 years. You’ve easily clocked up more than 10,000 hours, so why aren’t you running like an Olympian?
The answer is that not all practice is equal.
So what is deliberate practice?
Duckworth draws on the research of psychologist Anders Ericsson, who studied how experts in fields like music and sport train. The thing that sets them apart isn’t just the hours. It’s what they do inside those hours:
- They set a specific, stretching goal - not “get better”, but “shave ten seconds off my mile pace”.
- They give it their full attention and effort.
- They get feedback straight away, often from a coach.
- They reflect, adjust, and go again.
In my spare time, I like to do a bit of swimming. If you compare my swimming to the process above - I go to the pool, get changed and swim laps at a comfortable pace. No goal, no measurement, no coach. It’s great for my head, but it isn’t going to make me faster. The pros are doing something very different with their time - they train with focus rather than just going through the motions.
Where this shows up in software
This got me thinking about how we work in software engineering.
For years we’ve had Scrum, Kanban, Agile, SAFe and plenty more (just to name a few). The details differ a lot, but underneath they all share one idea - that a team should always be striving to improve.
Scrum is a good example. Retrospectives give the team a regular chance to look back, keep what’s working, and drop what isn’t. That’s your feedback and reflection step. Velocity and burndown give you a way to track and measure your work over time. That’s your measurement. Sprint goals give you something specific to aim at.
It’s easy to dismiss this sometimes. I’ve sat in plenty of retros that felt like a box-ticking exercise, and velocity can be gamed or misused as a stick to beat teams with. Those are fair criticisms. But they’re criticisms of how the practices get used, not of the idea underneath. The ceremonies are just a vehicle for deliberate practice.
Going through the motions
A team that holds a retro every two weeks but never acts on what comes out of it is my “run every other day” for 10 years. Lots of hours, not much improvement.
A team that picks one thing to get better at, tries something, measures whether it worked, and talks about it honestly is practising deliberately, whatever framework they call it.
A few questions to start asking your teams:
- What is the one thing we’re trying to get better at this sprint?
- How will we know if we hit the goal?
- Who can give us honest feedback on it?
- What did we change last time, and did it help?
Wrapping up
The label doesn’t matter. You can drop Scrum for Kanban, or Kanban for something home-grown, and it won’t make much difference if no one is being deliberate about improvement. It’s the thing underneath that counts.
Do your team’s practices actually help you improve, or are you just logging the hours? I’d love to hear how you approach it - leave a comment below. 🙂