In the context of 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.
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?
To be clear, I'm asking specifically what agile has to say, not what you think the right amount of learning should be. The former has a specific answer, the latter is subjective and not appropriate for Programmers
I rephrased the question title as a question, but my question remains the same (note the lack of change anywhere but this section and the title).
Most of the answers, while insightful, did not answer the question (But they were appreciated! :)
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.
I understand that 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.