Requirements Change and Agile

1. Requirements are ought to be changed. What might be a good set of requirements now, is not a good set in six months time. Even if the customers can fix their requirements, the business world isn't going to stop for them. And many changes in the business world are completely unpredictable.

2.It does not mean the predictability of software development is impossible. But it requires a lot of ceremony, plenty of time, a large team, and stable requirements :)

3. Most of the time, this is not the case. So how to overcome or control an unpredictable process? this can be done with the help of iterations. These small iterations (working systems and as short as possible in time) are short on functionality, but should otherwise be faithful to the demands of the final system. They should be fully integrated and as carefully tested as a final delivery.

4. Iterative development makes sense in predictable processes as well. But it is essential in adaptive processes because an adaptive process needs to be able to deal with changes in required features. This leads to a style of planning where long term plans are very fluid, and the only stable plans are short term plans that are made for a single iteration. Iterative development gives you a firm foundation in each iteration that you can base your later plans around.

5. The important and interesting question comes here is, if the software development is unpredictable, then how can we make cost estimations? A fixed price contract requires stable requirements and hence a predictive process. Adaptive processes and unstable requirements imply you cannot work with the usual notion of fixed-price. Trying to fit a fixed price model to an adaptive process ends up in a very painful explosion and this will put both the software development firm and the client in loss. But it does not mean you can't fix a budget for software up-front. What it does mean is that you cannot fix time, price and scope. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner.

6. Adaptive process leads to good advantages to the customer.
a. Client receives much more responsive software development.
b. A usable, although minimal, system can go into production early on.
c. The customer can then change its capabilities according to changes in the business and also from learning from how the system is used in reality.

7. In the adaptive approach, you need to to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren't so important, only the roles are important. Btu at the same time you have to make sure that people are not completely treated as resources, and they have to be mentored and you have to make them realize that there are very important to the project.

8. Developers needs lot of discipline to execute the process. Developers must be able to make all technical discussions. Such technical leadership requires a sharing of responsibility where developers and management have an equal place in the leadership of the project. Management still plays a role, but recognizes the expertise of developers.

9.Technical people have to recognize that entering management means their technical skills will wither rapidly. Ex-developers need to recognize that their technical skills will rapidly disappear and they need to trust and rely on current developers.

10. Agile teams cannot exist with occasional communication. They need continuous access to business expertise. Furthermore this access is not something that is handled at a management level, it is something that is present for every developer. Since developers are capable professionals in their own discipline, they need to be able to work as equals with other professionals in other disciplines. A large part of this, of course, is due to the nature of adaptive development. Since the whole premise of adaptive development is that things change quickly, you need constant contact to advise everybody of the changes.

11. A project that begins using an adaptive process won't have the same process a year later. Over time, the team will find what works for them, and alter the process to fit.

The first part of self-adaptivity is regular reviews of the process. Usually you do these with every iteration. At the end of each iteration, have a short meeting and ask yourself the following questions

* What did we do well?
* What have we learned?
* What can we do better?
* What puzzles us?

These questions will lead you to ideas to change the process for the next iteration. In this way a process that starts off with problems can improve as the project goes on, adapting better to the team that uses it.

While both published processes and the experience of other projects can act as an inspiration and a baseline, the developers professional responsibility is to adapt the process to the task at hand.

References:
http://www.martinfowler.com/articles/newMethodology.html