According to canonical agile development, what is the appropriate amount of learning that an engineer should engage in before implementing a solution to a problem?
If an engineer knows she is too ignorant of a given topic (say, compression) to start implementing, she goes and learns what she thinks she needs to know, and then implements a solution.
Clearly a deeper understanding of said topic could result in a better implementation, but at the cost of agility. On the flip side if an engineer learns too little about a topic, there is a danger she will implement a significantly insufficient / broken implementation that negatively affects customers in the immediate or near future. In some cases, not a lot of research is required, and in some cases developers are faced with a topic even the senior-most developer knows little to nothing about, so the answer to this question includes an element of scalability to meet both situations.
Towards which end of this scale, if any, do guiding principles of agile lead an engineer? Or does agile leave this as a sliding scale, where the answer may be different in any given situation?
In other words, I'm looking to understand not when/how inside agile development research happens, but moreover how to estimate a "good" amount of time to spend learning a topic in the research phase before moving on to implementing a solution.