How to Really Welcome Changing Requirements in Agile Environment

If you are one of those who is all set to start with agile development practices in your organization, check the following on how to deal with changing requirements which is one of the important specifications mentioned in Agile Manifesto.

If you want your team to accept the idea of changing requirements (hard to digest in the beginning and so resistance) while they are developing the code, following are some of the things you would want to adopt/encourage as part of software development practices to really make team welcome the changing requirements:

• Training:
  1. Software quality with emphasis on how to write maintainable/easy-to-change code
  2. Object oriented design principles to ensure the understanding on concepts such as reusability/code cohesiveness
  3. Unit Testing fundamentals and XUnit (JUnit/NUnit/MSUnit etc)
  4. Code refactoring techniques to help refactor/change the code
  5. Code review techniques
• Continuous integration: Setup continuous integration environment that takes care of some of the following:
  1. Run unit tests
  2. Automate the build & deployment process

  One could use tools such as Hudson or Anthill for this purpose. This makes sure that you deliver frequently deliver working software.

• Unit testing: All of the developers should be made familiar with key concepts of unit testing, and what does it take to write good unit tests; This does help in ensuring testability of the code which is key characteristic of code maintainability; This puts the technical debt in control in case of changing requirements and also ensure continuous delivery of “working” software given the chances of errors due to changing requirements; This makes sure that you deliver working software frequently of “Good quality”.
• Code review: One should propagate usage of code review tool such as Sonar (static analysis) and Crucible/Code Collaborator etc. to make sure that software of good quality is delivered
• Software Quality Metrics: To make sure that your team is frequently delivering software of good quality, it may be a nice idea to have some sort of metrics to measure at least some of the following:
  1. Defects density vis-a-vis velocity
  2. Maintainability (Testability/Reusability)
  3. Usability (Code readability)