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:

1. They set a specific, stretching goal - not “get better”, but “shave ten seconds off my mile pace”.
2. They give it their full attention and effort.
3. They get feedback straight away, often from a coach.
4. 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. 🙂

When building demo apps, the rule is you must build a calculator. It’s a simple understandable app which does not require explaination of what it does. For Tray-tober I had to build one at some point, but what was the unique angle going to be? Well it is a tray app and it is build with Rust!

Specifically Trayulator uses Windows-rs to keep the app using native APIs and UI! You might not have known that this is any different than a regular Windows app because the rust app is bundled up in a MSIX just like other apps. It is awesome that Windows app devs have so many great options that all work well with the other tooling.

Happy Tray-tober!

Joe

Marcin Klimaszewski: When Product Owner Success Creates Blind Spots for Agile Teams

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

"I am not the user. That is how I learned how important it is to keep your ego small." - Marcin Klimaszewski

Marcin Klimaszewski started in product as a webmaster, writing HTML and CSS, before discovering UX design through a colleague who became his mentor. That shift changed how he looked at software: not as screens to build, but as problems to understand. In this episode, Marcin shares an EdTech product story where the team had everything a product person could hope for: access to students and teachers, weekly validation, a strong Product Owner, and a confident team. The problem was that success started to distort the team's relationship with the rest of the organization. As the team received positive user testing feedback, they began to see themselves as the best team in the company. From the outside, that confidence looked like arrogance, and critical dependencies with sales, marketing, e-commerce, and payments became harder to manage. The product eventually launched, but never reached the sales targets. For Marcin, the lesson is sharp: user testing is not market testing, and Product Owners need Scrum Masters who help teams stay connected to reality before the market does it for them.

In this episode, we refer to EdTech and Product Build Day.

Self-reflection Question: Where is your team getting positive feedback that may be hiding the real market risk?

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

Buy Now on Amazon

[The Scrum Master Toolbox Podcast Recommends]

About Marcin Klimaszewski

Marcin Klimaszewski runs Product Build Days. One day to validate a business idea. Teams build the app themselves with AI tools, use synthetic users to sort out the usability, and design the sharpest test they can run the next day with real users. For founders, PMs, designers and other non-coders. An idea that cannot survive one day is not worth a quarter.

You can link with Marcin Klimaszewski on LinkedIn.

What would change if you treated every person on your team as someone else's precious cargo? A friend of the show visited her son at Fort Bragg and came home less worried, because his leaders clearly took responsibility for the people under their watch. That post sent Bob and Josh into what caring for your team actually looks like in practice: the standard Josh holds every leader in his org to, why so few leaders know how to develop people, what happens to "team first" talk when the pressure's on, and the small, almost free actions that tell your people you've got them.

What you'll learn:

• The measuring stick Josh holds himself and every leader in his org to
• Why most leaders never learned how to develop people, and what they copy instead
• How to walk into a PIP with the goal of getting the person back on track
• What happens to "team first" leaders when the pressure hits
• Why a final check on a parachute that's already been checked 10 times is the model for caring leadership
• Small actions that cost almost nothing and show your team you care (the broken-down car, the new baby, the next-day call)
• Why Josh stopped softening "I'm a team-first leader" in job interviews, and what it did for his career
• The 1 prioritization question that tells you what kind of leader you are

• Jennifer Fields's LinkedIn post

Stay Connected and Informed with Our Newsletters

Josh Anderson's "Leadership Lighthouse"

Dive deeper into the world of Agile leadership and management with Josh Anderson's "Leadership Lighthouse." This bi-weekly newsletter offers insights, tips, and personal stories to help you navigate the complexities of leadership in today's fast-paced tech environment. Whether you're a new manager or a seasoned leader, you'll find valuable guidance and practical advice to enhance your leadership skills. Subscribe to "Leadership Lighthouse" for the latest articles and exclusive content right to your inbox.

Subscribe here

Bob Galen's "Agile Moose"

Bob Galen's "Agile Moose" is a must-read for anyone interested in Agile practices, team dynamics, and personal growth within the tech industry. The newsletter features in-depth analysis, case studies, and actionable tips to help you excel in your Agile journey. Bob brings his extensive experience and thoughtful perspectives directly to you, covering everything from foundational Agile concepts to advanced techniques. Join a community of Agile enthusiasts and practitioners by subscribing to "Agile Moose."

Subscribe here

Do More Than Listen:

We publish video versions of every episode and post them on our YouTube page.

Help Us Spread The Word: 

Love our content? Help us out by sharing on social media, rating our podcast/episodes on iTunes, or by giving to our Patreon campaign. Every time you give, in any way, you empower our mission of helping as many agilists as possible. Thanks for sharing!

Since my previous article, there have been roughly 640 new commits to the Clang bytecode interpreter. Apart from the usual bug fixes, performance improvements, and smaller refactoring, the work resulted in these changes: