DRYness may be a design pattern you have heard of. If not; we are talking about Don't Repeat Yourself (DRY).
Disclaimer: no one is perfect and therefore neither is their work. We are talking ideals here not rules. Otherwise you would be reading developer rule #1....
Anyway, the idea is to do work only once. Every time you find yourself thinking : "if I just copy .... and change .... Code then ...".
There are lots of good reasons to only write your code once, unless you take the time to refactor your code at the end of a project then when some new developer comes along he will likely miss the X multiple versions. Think about it like this: you write some code with a bug, let's say an off bye one that only happens on the 29th of February. Someone tries to fix your code but doesn't realise that you have pasted the same loop in four places. Even if they fix it they may not run a search to find all of the other cases.
Once you want to start thinking this sort of approach is a good idea other goodness comes for free. If you want to start writing code that is reusable then you have to start thinking about higher levels of encapsulation. You might also think about refactoring your new method or helper class so that all configuration is parameterised. This is great news from a testability point of view too. You can write one set of tests for your new function and the scope of your test plan is limited to your parameter list.
The bottom line is if you are going to write [crap] code at least make it DRY. That way when your agile approach makes you realise you need to fix the problem you deferred you only need to do it once, you may even thank yourself in the future for your own fore sight.