Change is an important part of Agile. Every person in Agile should be willing to change and to accept change. No one disagrees with that, at least not in the Agile world. But why is it that in the Agile world I see so much resistance against change?
Fear of change
When building an application or website, you don’t know what to build yet. Well, you have an idea of what to build, but that might change. That is why Agile exists, you might say. But when a developer starts building it, it becomes clear: change is not always welcome.
What becomes clear is a fear of change. And this can be divided into two fears. The first one is the fear of taking too long. The work was estimated and with every change, it becomes longer and longer. And, Agile often doesn’t change that, you made a promise to finish at a certain moment or to finish a certain amount of work. Or even worse: you have a deadline.
The second one is the fear of no preparation. If you want to do your work with good quality, you need to prepare. You need to think about it. For example: how is this change going to affect the current database, the current screens, the current workflows? But a lot of changes are combined with: I want it now!
Permission to change is not equal to permission to change now
In Agile you have permission to change. But that doesn’t mean all changes must be done immediately. This might sound like something managers and clients don’t want. Why would a manager or client accept to move a change to a later moment? Because they do not want the downsides.
If a change is important for a customer or manager, it should also have a certain quality. And it’s also important that the rest of the product keeps a certain quality. Building it right now often will not give that quality, because it will be rushed. And everyone knows the quality of rushed work.
Also, a client/manager wants the promised work or timeline. So the question becomes: is it worth spending this time on this change? Is the change worth not getting some other functionality or getting the product later? Sometimes the answer will be Yes, but often it will be No.
Permission to change is not equal to permission to change whenever you want
Another responsibility for change management is with the tester, reviewer, or any person that needs to accept the work. One of the things that really cost a lot of time is the fact that the review isn’t passed over and over and over again. Every time a person looks at it, he or she notices something that needs to change.
When a test or review is done, I often mention these two rules:
- Try to test or review as much as possible the first time you see it
- If you don’t see it the first time, it probably isn’t important
The second one might give some discussion, but most of the time it is true. If you, as an expert, missed it the first time, it’s very unlikely someone else will notice it. And, if so, it will make them say: what a bad product this is.
How to handle change properly
So how do you handle change? You think about these three questions:
- Are you willing to accept less work or a later delivery for this change?
- Does it matter if the quality is lower because of this change?
- Is there any way I can find more changes at once?
If any of these answers make you not do the change right now, that doesn’t mean that you are against change. It means that you want to change with good quality and planning skills. I would say there is nothing wrong with that.