Agile Development: Core Values

In my last post, I talked about some of the advantages of and potential problems with using Agile as your development philosophy. Today I’d like to build on that topic by talking about the fundamental principles that guide Agile development. There are four, each seemingly described as a choice between two competing priorities:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

In reality, the core values should not be taken as “do this, NOT that” statements, but rather as reminders that help the team prioritize the activities and attitudes that create the most value.

1. Individuals and interactions over processes and tools

The first core value is my favorite one: start with the right people, then build your processes and select your tools to best fit them, rather than the other way around. A good development team will build good software; how they build it is a secondary concern, albeit still a valid one: just because your star engineer likes to code in original Fortran, it doesn’t mean you should fill a couple of rooms with IBM-704s. Choosing the right tool is important, and will improve your team’s ability to produce quality software, as well as team recruitment.

Still, it’s the people that matter, and in particular their interactions with each other and with other parts of the organization. The key to building great software is teamwork. Individual skill plays a role, but without open communication and commitment to the team’s goals, the end product may look great, but it will likely not fulfill the original customer need, or it will do so in an inefficient manner. Agile’s daily standup meetings and end-of-iteration evaluations are a way to encourage the team to communicate freely and check egos at the door.

2. Working software over comprehensive documentation

This is the one that often makes developers jump for joy! An Agile team’s focus should be on finding the most efficient way to build software that solves an identified need, and therefore should not spend a lot of time on paperwork. Agile documentation should answer two basic questions: what are we going to build (project requirements and user stories) and how did we build it (technical specifications). The former is crucial for keeping the team focused on the ultimate goal during the fast and furious development sprints, and the latter is needed later on for the purpose of revisiting a certain project, be it to make enhancements or corrections or to reuse a particular feature. Anything else is typically overkill.

3. Customer collaboration over contract negotiation

The best way I can think of to explain this core value is: the development team needs to think of the customer as another member of the team. The customer-team relationship should not be managed by a signed piece of paper, but rather by the ongoing needs of the project. Contract negotiations (you can  calm your legal department down at this point; yes, there will be a contract) should be focused on identifying the problem that needs to be solved and a clear set of success criteria that will tell us we’ve solved it, rather than the tool or process to be delivered. Provisions should be made for regular customer-team interactions (say, by involving customer representatives in sprint planning and review meetings) and a clearly defined change management process: software development is a journey, and the team should have the flexibility to change course midstream if doing so will make the end product a better fit for the customer’s need.

4. Responding to change over following a plan

I talked about requirements documentation earlier, so there is, in fact, an overall plan. What this core value means is that those requirements are a suggested path to solving a customer need, and they can be modified throughout the project if prior development work uncovers a different, better path to the solution, or even a better solution altogether. And in this case, better means more efficient. In fact, everything I’ve described can be summarized in one, overarching principle: identify the problem to be solved or that needs to be fulfilled, and find the least costly way to get to that end point; do this at the beginning of the project, and keep doing it over, and over, and over again until everyone agrees that a solution has been reached. Everything else (processes, tools, plans, documentation) either makes it easier for the team to find that solution, or is superfluous and should be eliminated.