"Why Adopt Agile?"
Here's his complete question:
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."
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.