ABSTRACT
Technology changes, competition changes, organizations
change, regulations change, and systems must change with
them. Since Agile processes deliver in small batches of a
few requirements at a time, there is more of an ability to
adapt to these ever-changing requirements. When tradi-
tional teams put months of work into requirements and
months into design, there is a tremendous amount of
momentum in place that works to maintain the current
path even if that path is no longer relevant. Huge invest-
ments have been made up front and strong change control is
implemented in order to achieve the plan. However, Agile
takes the attitude that the plan is not the goal; a suitable
system that solves the business problem is the goal and if
requirements must change or feedback from prior iterations
uncovers new information, then the system and the team
must adapt accordingly. And since Agile teams do not
typically invest huge amounts of time up front on detailed
requirements, if a requirement does change, there is typi-
cally a lower cost to allowing the change and satisfying the
business need. The Agile manager should not instinctively
run toward tight change control when using theAgilemodel.
