September 4, 2012 | John Rusk Agile has always embraced change. But businesses are still be tempted to minimise those changes, by trying to get things “right” first time. On my current project, we’re realised that minimising change is not necessarily a good thing. Why? After the system goes live, we must be able to change it. (In our opinion, an unmaintainable system would be a failure.) So… if we are going to successfully change the system after go-live, then we must practice making changes before go live. Without such practice, how would we know whether the architecture is maintainable? How would we know whether the team has the necessary skills and confidence to safely change the code? So each mistake, dead-end, or change of direction has a silver lining: it’s a chance for us to practice the essential skill of changing our code. We need these mistakes to happen, so we can practice correcting them.