The very first project I managed – this too without any formal training, understanding or appreciation – was unfortunately with a distributed team where the tools were limited to Word and Excel. I remember the version control was Visual Source Safe configured to lock a file to checkout and make changes to. Requirements (Functional Specifications and Technical Specifications) were emailed in the form a Word document for us to estimate. One key component of the release was a feature that was full of SQL procedures. The developer looked at the requirements and attacked the problem with great gusto. A week before the release we found out that the entire idea had been misunderstood needing us to rewrite the whole thing. A lot of fingers were pointed, reputations lost, divisions created. Would this have been allowed to happen in an Agile project? Probably not – this is extreme. Lets look at why.
Communication: There is such an emphasis on communication in Agile that it will be very hard to not know what someone is working on and how that work is doing. We look at daily stand ups and iteration planning in more detail later.
Progress: There is no concept of being 80% done. Every big requirement is (ideally) broken into smaller, value-adding features that can be tested, feedback provided and changes made. Since this is done at the very least 2 weeks, if done right you have the opportunity to course correct. Of course this typically happens every day.
Tools: The strong emphasis on communication requires tools that foster this. Git, hipChat, wikis, story boards, video communication – all of this helps to keep the team connected and in the loop.
Agile is in this context a software development process that emphasizes on iterative development of software. The principles of Agile is espoused in the Agile Manifesto.
We value individuals and interactions over processes and tools.
We value working software [or any product] over comprehensive documentation.
We value customer collaboration over contract negotiation.
We value responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more. (www.agilemanifesto.org)
The principles are not necessarily limited to those stated explicitly in the manifesto. There are others like Servant Leadership which though not explicitly outlined in the Manifesto goes well with Agile.
The main reason for the adoption of Agile practices is to make software development more effective in a world where change is rapid.