"Why Adopt Agile?"
Here's his complete question:
"Hey all,
I figure we often get asked the question by executives and engineering teams "Why should we adopt agile?" I wanted to better articulate my argument to my team, and hope that a few of you may bring insight into reasons to adopt Agile that I haven't thought of before."
http://www.linkedin.com/groups/Why-Adopt-Agile-81065.S.5842362499172704258?view=&srchtype=discussedNews&gid=81065&item=5842362499172704258&type=member&trk=eml-anet_dig-b_pd-ttl-cn&fromEmail=&ut=1XBI14jvlLxm81
Since I believe he is probably not the only one with this question, I have decided to share my response here:
Communication.
Communication. Communication.
Everything we do boils down to communicating. In Software development we
get requirements from the business and attempt to turn them into software. In the waterfall world you gather all the
requirements in front with the assumption that all the requirements can be
gathered and they won't change over time.
If you can get a comprehensive list of requirements and spend enough
time up front figuring out how you will build it, if the business approves the
design, you'll be set. The problem is
those assumptions are simply wrong.
Requirements will change. The team’s understanding of requirements will
change. Problems that could not be foreseen in development will arise and they
will impact the design. These are the
main reasons Waterfall projects fail.
Sure they try to manage things like scope and make it very hard to
change scope. But if you don't allow the scope to change, you will deliver a
product that is no longer what the business wants or needs. On the other hand we all know that allowing
scope to change in a world of Big Up Front Design (BUFD) is extremely
expensive.
Agile addresses these issues through effective and frequent
communication with the product owners (the business). Short Sprints give short
feedback loops. Constant discussions
about changing priorities and requirements can be addressed, entered into a
backlog, and tackled with very low cost in the very next Sprint. Requirements are gathered via user stories. The reason for having user stories is to
facilitate discussions between the developers and the business about what it is
they think they need. The requirement itself is captured on a 3x5 card that can
be discarded on a moment’s notice if a "story" (requirement)
changes. At the end of a Sprint, the
business can see functioning software and can tell immediately if what was
delivered by the team, was the thing they intended to be built or something
different. Feedback is shared and corrections can be applied in the next
Sprint.
Agile does all the same things as waterfall: requirements gathering,
design and release planning, construction and testing. But it mitigates
risk in several ways. First, it
shortens the cycle for feedback to the length of your Sprint (usually 2-3
weeks, instead of months) Second, it involves the business intimately with the
design, development, and construction through each process rather than at the
end of each process making it easier to accommodate change. Third, it delivers
function software at the end of each Sprint.
So the business has something that works. If you halt a waterfall project before the
construction phase is completed, you have piles of documentation that can't DO
anything.
Agile is the way to go because it minimizes risk to the business by
emphasizing communication and constant feedback while delivering functional
software. This is something
the business cannot duplicate with weekly Status Reports.
Agile software development eliminates the unnecessary
artifacts that are often required to give some architect or business person a
warm fuzzy and replaces it with intimate involvement in the project. It moves quickly and embraces change.
In a business world that has become almost wholly dependent
on technology and technology that changes at incredible speeds, Agile is simply
the safest thing for a business to do.
