Developing software is an incredibly complex and challenging undertaking. Historically, the process has been fraught with missed deadlines, unacceptable bugs, and sometimes incomprehensible features that users would never want. In the early 2000’s, these projects had reached nightmarish proportions – perhaps no better exemplified than the disastrous release of Windows Vista, a project that was a year late and a commercial failure. Projects like this were largely seen as incapable of being released successfully.
To encourage better ways of developing software a group of 17 methodologists formed the Agile Alliance in February of 2001 in a ski lodge in Utah. The group recognized the difficulty of creating good software and wanted to instill new values into software development teams; thus the Agile Manifesto was born. The manifesto defines the values and principles software teams should adopt in order to achieve the ultimate goal of creating good software.
A good way to think about the manifesto is that it defines values, not alternatives, encouraging developers to focus on certain areas but not eliminating others.
Individual and interactions over process and tools
This first value places its emphasis on teamwork and communication. Teams of people build software systems, not tools. And to do that they need to work together effectively through productive interactions.
Tools are an important part of developing software but think of it this way: Who do you think will develop better software? Five software developers with their own separate but unique tools working together in a single room – or five isolated individuals with a well-defined process, a common set of the most sophisticated tools and a huge office? Obviously the team will perform better. Making great software depends much more on teamwork, regardless of the tools teams are given. Think of the motto, “A fool with a tool is still a fool.”
But don’t take this first value too literally. It’s not that tools are unnecessary. Tools and processes are still key to developing software. Without the right tool or process your team will struggle. The point is that the tool should fit the team’s needs and process – not the other way round.
Working software over comprehensive documentation
User: This feature is confusing and I’m not sure how to use it.
Developer: Well you should have read the manual.
Let me make an extreme point: documentation is a crutch that software developers rely on as an alternative for making software that works well.
Documentation definitely has its place and can be a great resource or reference for users or co-workers who are wondering what the software is and how it works. But often times you might find yourself in a company where they need the documentation before you can even create the software.
Customer collaboration over contract negotiation
Only your customers can tell you what they want, and it’s your job to listen. Successful development teams work closely with their customers and communicate with them frequently. Of course they will not be able to tell you the next breakthrough idea (that’s your job), but by listening and getting feedback you will understand what they truly want out of your product.
Responding to change over following a plan
Change is the reality of software development – technology changes, business trends change, customers change. There is nothing wrong with a project plan – however, it must be malleable. There must be room to allow for change and to respond to it otherwise your plan quickly becomes obsolete.
