Agile Development – Change is constant!

Often I see that whenever there is a change in requirements from the client, the developers tends to get de-motivated.. unwilling to change the codebase.. I hear comments like: 

• They are not clear on what they want 
• They should first define their requirements and then move forward with this 
• Our marketing team would accept just everything that client wants without pushback 
• Frequent changes will destroy the design

.. all pointing that we developers are unhappy and someone there is not doing the job correctly.

Times have changed and we are agile. Change is reality; business is changing every second. Think as if you have your own business - would you not like to make changes as you go, may be your vision changes with market, may be you want to do something different based on your competitors or based on some new innovative ideas and so on.. When your customer is asking for a change, it means a lot to them. It means a lot to the value to end-users that will be offered by the product you are eventually helping them to create. By buying into this change you are helping a wider community.

Agile methodology is all about accepting the fact that - change is constant. Agile helps to manage change. Does agile then mean that we keep changing things? I guess no. We should definitely reason and demand that why there is a change. We should evaluate and suggest the client if the change is not for good or if there are better alternatives. However, we should also understand that why someone wants to change and if this is genuine change, then we should embrace it.

Ten tips for Clients and developers involved:  

1. Reasons for change should be conveyed. People should buy into the idea. It also will help you validate and understand implications of the change and also invite other cheaper/better ways to have that incorporated. 
2. Frequent changes means that something could be going wrong. May be vision has a problem. May be execution strategy is not concrete, may be this is not the right time to start... And yes, implementing a change does costs something. 
3. A change control board (CCB) consisting of client stakeholder (Product owner and others) and vendor management/arch/lead responsible for change management should be trusted.
4. Change needs time to implement, this should be scoped well and included in the plan.
5. Developer’s can fix a problem as a hack or can provide proper desirable fix. If time will not be provided to implement the changes, changes can still be done but will involve hacks. Hacks will deteriorate the overall quality making system costlier and difficult to change as month’s passes by.
6. Design a flexible architecture which meets the current spec out requirements. Don’t overdesign and do accept the fact that design will change.
7. You can minimize the efforts by using appropriate design patterns, by following design principles.
8. Follow agile, follow refactoring, follow TDD... They will ease changing code.
9. Enjoy changing code, see how your design handles the change, you will definitely learn new ways of refactoring and also newer ways to design your next system.
10. Refactoring is fun. Once you achieve it and then when you see cleaner code you feel happy about it. And once change is delivered and it’s making difference in end-users life, that’s the real reward you get.

Next time you are facing a change, do question it and once answered, embrace it with affection. Change is good.