If you ever being in a team which practices agile software development, you might already heard about how a software development team “welcome chnging requirements”. While it sounds great, I personally think, if this statement is not properly explained, the impact will be negative on the development team side. Now, let’s see the complete statement:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
The statements come from: Principles behind the Agile Manifesto. Reminder first: YMMV. I don’t usually consider what I write is the right one, the more human involves in the subject, the more it usually “depends on context”.
I used to be a believer in the Agile Manifesto but looks like things are not going as initially intended. In practice, changing requirements always has negative impact, it shows incompetencies. Although changes are possible (and in many cases, they are certainly will happen), we must manage them properly. Without properly managed changing requirements, agile development will only embrace chaos in software development and chaos is not good for developers. So, how should we manage them?
- Have a proper software architecture.
- Use semantic versioning to manage software releases, based on the architecture.
The problem in the statement is rooted from client (product owner) who may feel that they may change their requirements and because they don’t have knowledge in software technology (usually), request for changes can vary from minor into major as they don’t know the impact of changes to software process. This is not good. Agile should not blatantly advertised that statement without proper explanation.
