The Agile Values

The important thing to understand about the four value statements is that while you should value the concepts on the right hand side you should value the things on the left hand side (presented in red) 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 values of the Agile Manifesto are:

1.     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.

2.     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?

3.     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.

4.     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 understands 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. 

The interesting thing about these value statements is there are something that almost everyone will instantly agree to, yet will rarely adhere to in practice.  Senior management will always claim that its employees are the most important aspect of your organization, yet insist they follow ISO-9000 compliant processes and treat their staff as replaceable assets.  Even worse, management often refuses to provide sufficient resources to comply to the processes that they insist project teams follow.  Everyone will readily agree that the creation of software is the fundamental goal of software development, yet insist on spending months producing documentation describing what the software is and how it is going to be built instead of simply rolling up their sleeves and building it.  You get the idea – people say one thing and do another.  This has to stop now.  Agile developers do what they say and say what they do.