You would definitely like to deliver the right software without defect on schedule. But in real life…

Imagine a situation where your software delivery date is very near and everything is under control. You are almost ready with the tested software. Suddenly you receive a request for change from the user.

Your first reaction would be not to entertain the change request now and postpone it for later cycle. But after discussion with the user you realize that without that change the software would loose most of its effectiveness.

Now what do you do?

If you are following traditional methodology then your decision would be simply – you would go by the signed-off requirement and deliver the software. If that is not acceptable to the user then you would ask for an extension. After all, if user can change requirement so late in the life-cycle then you can definitely ask for more time.

But, if you are following agile methodology…

“you welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

So, what do you do?

• Do you compromise the quality but incorporate the change and release the software? Or,
• Do you release the software without the change and try to convince the user that the changes would be done in the next iteration? Or,
• Do you delay the release to properly incorporate the change?

If you have been developing software you would be constantly facing this dilemma.

Adopting Agile would not eliminate the problem but change your attitude towards the problem.

Udayan Banerjee on Google+

More Reading

• Agile Adoption – Crossing the Chasm