As there seems to be a bit of debate on where exactly the question is heading, I'll try to give a few pointers:
In non-agile process models you typically have changes being made to requirements, which roughly corresponds to your scenario. In that case, the effects are especially easy to see when you consider the waterfall model: you have to go through your whole product and all previous process steps in order to adjust for the new or changed requirement.
In Agile development, before you start your sprint you should have a meeting to discuss which user stories/epics/features/.. you plan to realize in the upcoming sprint along with an estimation of the required efforts. It is this latter emphasized part, where you as a team member should raise the bar significantly if you see that a major design change and lots of refactoring will be required.
Everything becomes more problematic, the less competent the team is of course. So, if you get told a user story and you say you can implement it in 2 weeks, but only later come to realize that you need to redesign and it'll take you at least 4 weeks, it is too late. You will already be mid-way in the sprint and the sprint will fail. At this point, the only option pretty much is to cancel the sprint right-away. You re-start at that point by having a new meeting and look at the user stories you want to realize in the then next sprint including your new knowledge of the design problems, which will lead to more accurate time estimates.
To finish with a more positive statement than that: It does help enormously to rely on good time estimation methods (f.ex. planning poker) in order to reduce the risk of estimates going way off.
To extend the answer with regards to your comment: Code quality ensurance remains basically unchanged by this. You ensure code quality by testing, and you do so no matter if you have to redesign or not. Of course, a chair cannot be cast into a table. But this simply means, that you have test cases which try to do that, but fail. This is actually the easy case (because the failure pops up easily when you run your tests), in which your test no longer matches the updated design. Do not forget that the process of redesigning involves updating your existing tests. If requirements change, your old tests cannot be trusted anymore!
Here are a few pointers to articles specifically on testing in an Agile context.