One of the principles of the Agile Manifesto is “technical excellence enhances agility.” This is a crucial principle; you can’t expect to have success unless your technical skills are as high as possible. Trying to be agile without paying attention to technical issues is dangerous.
Think about it: when you work in an agile team, you give up doing extensive requirements before coding. This increases the likelihood of getting totally unexpected requirements halfway through; requirements that your architecture does not support (and here I define architecture as “that which is difficult to change later”). Then you give up an extensive design phase. This increases the risk that your codebase will turn into a ball of unmanageable spaghetti.
Agile methods use specific practices to compensate for the absence of the requirements and design phases: test-driven development, refactoring, pair programming and simple design. But these practices _are not easy to do_. Before you even attempt to be agile, you should get your fundamentals right. This means you should know your operating systems, algorithms and data structures, design patterns, object-oriented design and even UML by heart. For how are you going to do “simple design” when you don’t know what your design options are? How are you going to refactor, if you don’t know where to refactor to?
The theory I’m talking about is the work of, mainly, Sir Tony Hoare and Robert Floyd, who invented the axiomatic theory of programming, and Edsger W. Dijkstra, who pioneered the idea of developing a program and its proof of correctness concurrently, in small incremental steps.
A modern introduction to the subject is Program Construction by Roland Backhouse.