Marko Anastasov wrote this on November 29, 2011
Agile and change
It happens that people identify themselves with a piece of work that they did. From a purely logical perspective, this does not make any sense, and generally it is a guaranteed way to lose your personal tranquility. Yet it’s sometimes difficult to control, especially if you don’t practice it somehow.
To a programmer it may occur on both code and feature level. You think that something is such a great piece of code that it’s a pity to remove it. The more time you’ve spent on it, the greater the feeling. It influences your thinking in a situation when you’re asked to discuss the real user value of it.
That’s one aspect where agile shines. When you’re writing a spec first, that flow has framed the implementation code for you differently. It is more like a means to an end - to make the nice test pass. And that’s good because your code is a means to a user’s end. So you’re not personally attached to it.
And when you’re collaborating with your client daily, he gets to see the direction where you’re going with a larger feature when it’s 20% done and not 99% done. It’s a great framework of collaboration where nobody is afraid or opposed to change for any reason. Indeed, you will embrace change, as change is natural and feel a boost every time you refine your creation to better match the product.
