How to adopt time boxing without adopting an entire Agile methodology

One way you can "do Agile" without adopting an entire methodology or attempting an "agile transformation", is to adopt time boxing: the idea that you never move deadlines in response to resource crunches or delays; you instead reduce the amount of work delivered at the deadline. A "sprint" is simply a 1-2 week time box, but there is nothing preventing you from applying the idea at different time scales. For example, the popular Pomodoro technique for time management uses a 25 minute time box.

A better example: if your team hasn't mastered CI/CD yet and still rely on nightly builds, you can make your day a time box. Each developer picks a set of stories/bug fixes that they aim to deploy to QA before an evening code freeze (say 5pm). Whatever's incomplete or leftover by 5pm, gets spilled over to the next day. What you do not do is extend the deadline to push through some "last minute" work (unless it's a genuine business emergency). If you miss the train, you must catch the next one.

While this may seem inconvenient at first, it forces teams to adopt several useful disciplines:

One, slicing work into small enough, testable slices. If you have aimed to complete two deliverables (e.g. stories) in a given day, and you miss the last one by a hair's breadth, your delivery for that day will be 50%. But if you had sliced those deliverables into 5 smaller (but still independently QA-verifiable) deliverables, your delivery will now be 80% (one 1 of 5 missed).

Two, it forces you to take a closer look at your capacity and see what can reasonably fit in, before starting the work. E.g. out of your 8-hour day, if you already know that you have set aside 2 hours for meetings and responding to emails, your capacity, or the size of your time box is 6 hours. If your typical stories are, say, 2 hours, you can reasonably commit to delivering only 3 slices by the end of that particular day. And you know that even if you miss one, QA can at least verify the remaining 66%.

The above is just an example. This can be applied at any scale, using any unit. E.g. for a whole team, over the span of a week, using some other unit of measurement (e.g. story points, of which I'm not a big fan). Once again, the key: never move the deadline, reduce scope of delivery. And slice your deliverables to independently verifiable bits so that if you miss one, your delivery doesn't drop by a large percentage.