Yeah the really easy methods are when the game has functions that you can push that little bit further, or otherwise abuse. Not so many games have these though, mind you life is getting better and I am seeing increasing amounts of games with such options.
"manually change the animations and animation time"
Most GBA 2d animation is done via the so called OAM (or the rough equivalents in the BG part of the setup). It allows you to choose the locations of sprites on the screen and which one is displayed. Swap between two or more different ones (I am sure you have seen a spritesheet before) and move them at the same time and I am sure you can see how animation happens.
The game will tend to run a loop like add 2 px each time, once the total added/position = blah then stop/make sure you are on rest sprite. You can change this to be 4 px each time with relative ease (you watch the OAM that handles this, that will give you the instruction that did the deed and then you move backwards from there, though you will probably not need to do a lot), the trouble tends to come in that the game functions are not built to handle oddities like you would be introducing there. For instance it costs you or I no great amount of brainpower to tell over 20 but it is still quicker for a computer to tell if something equals something rather than is greater than, the C family of programming languages (which the GBA mainly used) separating things well enough here. You change the "add 2 to location" function to "add 4 to location" and suddenly the part of the function that checks to see if something equals 18 is going to go into a massive loop. You might not have this and it is easy enough to figure out otherwise. Alternatively you can make it jump directly to the location you want; in FFTA you probably only care about the grid, make it jump a grid tile every time rather than the full animation and the game should hopefully sort itself.
The third and absolute hackjob method is fiddle with vblanks and interrupts there. In the GBA, and most other systems have fairly similar functions, then 60 times a second there is a v(ertical) blank of the screen and the processor moves to handling things set to happen then, strictly speaking this is the only time you should update the screen for a lot of things. By changing what waits for a vblank to something that happens more often (60 times a second is 60Hz, even on something as lowly as the GBA we are still dealing in megaHertz (millions per second)) then things tend to happen faster. The graphics will probably break, it is not unlikely that the game will crash, the console may explode, the Ninja King may sense something is wrong and kill you to put it right... generally it is bad news, I mention it mainly to be more complete. Mind you the game might also count the vblanks between animations (60 times a second is still very fast for a lot of animations after all), if you can change how this count operates (once every 20 do animation becomes once every 10) you can also do good stuff.