Agile


Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

The values of the Agile Manifesto are:

Individuals and interactions over processes and tools. Teams of people build software systems, and to do that they need to work together effectively - including but not limited to programmers, testers, project managers, modelers, and your customers. Who do you think would develop a better system: five software developers and with their own tools working together in a single room or five low-skilled "hamburger flippers" with a well-defined process, the most sophisticated tools available, and the best offices money could buy? If the project was reasonably complex my money would be on the software developers, wouldn't yours? The point is that the most important factors that you need to consider are the people and how they work together because if you don't get that right the best tools and processes won't be of any use. Tools and processes are important, don't get me wrong, it's just that they're not as important as working together effectively. Remember the old adage, a fool with a tool is still a fool. As Fred Brooks points out in The Mythical Man Month, this can be difficult for management to accept because they often want to believe that people and time, or men and months, are interchangeable.

Working software over comprehensive documentation. When you ask a user whether they would want a fifty page document describing what you intend to build or the actual software itself, what do you think they'll pick? My guess is that 99 times out of 100 they'll choose working software. If that is the case, doesn't it make more sense to work in such a manner that you produce software quickly and often, giving your users what they prefer? Furthermore, I suspect that users will have a significantly easier time understanding any software that you produce than complex technical diagrams describing its internal workings or describing an abstraction of its usage, don't you? Documentation has its place, written properly it is a valuable guide for people's understanding of how and why a system is built and how to work with the system. However, never forget that the primary goal of software development is to create software, not documents - otherwise it would be called documentation development wouldn't it?

Customer collaboration over contract negotiation. Only your customer can tell you what they want. Yes, they likely do not have the skills to exactly specify the system. Yes, they likely won't get it right the first. Yes, they'll likely change their minds. Working together with your customers is hard, but that's the reality of the job. Having a contract with your customers is important, having an understanding of everyone's rights and responsibilities may form the foundation of that contract, but a contract isn't a substitute for communication. Successful developers work closely with their customers, they invest the effort to discover what their customers need, and they educate their customers along the way.

Responding to change over following a plan. People change their priorities for a variety of reasons. As work progresses on your system your project stakeholder's understanding of the problem domain and of what you are building changes. The business environment changes. Technology changes over time, although not always for the better. Change is a reality of software development, a reality that your software process must reflect. There is nothing wrong with having a project plan, in fact I would be worried about any project that didn't have one. However, a project plan must be malleable, there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant.