I've been doing something like this about 33% of the time for the last couple decades. The Agile guys glommed on to time-boxing and called it "sprints" but seemed to think time-boxing is only effective at multi-week scale.
A couple jobs back we experimented with coordinating our time-boxes (gang scheduling) when we were working in the same code base. We would do four 45 minute chunks, then spend 5 minutes emailing / slacking each other and 10 minutes to play beer-pong (actually it was set aside for chatting if we needed to chat.)
The rest of the day was spent sorta however you thought you might need to spend it.
Sometimes we would do it all day long. Some days we wouldn't do it at all. But a lot of us got into the habit of picking a small bit of work, doing it, then seeing where you are in the overall process. It also helped us avoid rabbit-holes. Our dev culture evolved to this place where people waited until the top of the hour to chat with co-workers unless it was an emergency. That was pretty cool 'cause you had a reasonable expectation of getting 45-55 minutes of uninterrupted coding time.
I definitely recommend recruiting co-workers to try it if you're working with other people in the same code base.
Demo-driven development is a great forcing function and it can work.
Also when you demo something to the management/stakeholders, you communicate progress, and even can get some additional funding/budget/time.
When you demoing for yourself/team, you can get more confidence in yourself and some dopamine.
This can be relevant:
My approach to building large technical projects (mitchellh.com)
https://news.ycombinator.com/item?id=36161397