| To address the challenges faced by software developers, an initial group of seventeen methodologists formed the Agile Software Development Alliance (www.agilealliance.org), often referred to simply as the Agile Alliance, in February 2001. An interesting aspect of this group is that all members came from different backgrounds yet were able to come to an agreement on issues that methodologists typically don't agree upon. This group of people defined a manifesto for encouraging better ways of developing software, and then based on that manifesto formulated a collection of principles that define the criteria for agile software development processes. The manifesto is defined by four simple value statements. What is most important to understand about these statements is that while you should value the concepts on the right-hand side, you should value the concepts on the left-hand side (presented in italics) even more. A good way to think about the manifesto is that it defines preferences, not alternatives, encouraging a focus on certain areas but not eliminating others. The Agile Alliance manifesto values the following: 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 customers. Tools and processes are important; it's just that they're not as important as working together effectively. Remember this old adage: A fool with a tool is still a fool. Working software over comprehensive documentation. When you ask users 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? Ninety-nine times out of a hundred, 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? Documentation has its place, and when 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. Customer collaboration over contract negotiation. Only your customers 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 time. 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, 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, and 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, but it must be malleable, allowing room to change it as your situation changes.
To help people gain a better understanding of what agile software development is all about, the members of the Agile Alliance refined the philosophies captured in their manifesto into a collection of the following twelve principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter time scale. Businesspeople and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity the art of maximizing the amount of work not done is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Stop for a moment and think about these principles. Is this the way your software projects actually work? Is this the way you think projects should work? Reread the principles again. Are they radical and impossible goals as some people would claim, are they meaningless motherhood-and-apple-pie statements, or are they simply common sense? They sound like common sense to us. |
