The agile way, quick and dirty. Find the code for whatever task you're supposed to do and change it. You do not try to place it on some grand master blueprint like in waterfall. Nor do you, according to agile, need that blueprint to add a new feature. If your code change breaks anything then tests will fail. Now you've got regressions, that's a task if you need one. Don't build any extra abstractions. Don't make your code overly generic. Go back and add those only as they become clearly needed and necessary. The general sentiment is that we don't know what tomorrow will bring, so fix it for today and if we need to redo it later we'll do just that.
You ask for the big picture, agile's answer is that there is none. The whole code base is alive and trying to keep on top of everything else that's happening is too much wasted time. You just keep the bits and pieces you work on working as you make changes. If the architecture becomes a problem then we'll make that a refactoring task to solve that particular issue, but it's never a full review. If agile was to create driving directions they'd go something like "Take the road going closest to the direction you want to go. If it becomes rough, carry on as it's probably better to get through that go back. If you really hit a dead end, make the smallest possible backtrack that lets you get around it."