Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
the right, we value the items on the left more.
| Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler | James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick | Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas |
© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.
What does this really mean? Does it mean that there is no plan? that no documentation is required? that processes and tools don't matter? Not at all. These are important but not as important as their counterparts - Responding to change, working software and individuals and interactions.
Let's look at these individually. The first is Individuals and Interactions over processes and tools. What they are saying is that in order to effectively collaborate and meet the customer's needs, we need to interact with others in a positive way. The idea is that we shouldn't get hung up on the processes and tools to be used, rather talk to people and value their input. Diverse viewpoints help to strengthen a team as long as the teams values the individuals and listens to them.
Working Software over comprehensive documentation. Here they are saying that the focus on the team should be to create working software without getting hung up on documenting everything. That's not to say that some documentation isn't important, just that the working final product is more valuable than volumes of documentation. The documentation should be enough to explain the logic and choices so that a future team needing to revise the software can easily understand the choices made.
Customer collaboration over contract negotiation. This one is a little trickier as it values working with the customer and getting their input as the software is created. The idea is to not have to have everything go through lengthy negotiation and formal change orders. That's not to say that some negotiation isn't needed, but that it shouldn't be seen as a battle to be won or lost. The end result should be something that both sides feel good about and that they had input into. Too often the contract negotiations seem to turn the developers and the customer into adversaries instead of allies. It is much easier to work with and ally and value their input than it is to work with someone seen as the enemy.
Responding to change over following a plan. This is a big one that can get out of hand rather quickly. The idea is that we recognize that we know very little about the final product and how to get there at the start of a project. In traditional project management this is when we would lay out the entire plan and then try to stick to it, even though we really didn't have a lot of information as to whether it is right or not. This can result in a lot of wasted time and effort building the wrong thing because you won't know it is the wrong thing until very far down the road. In agile the feedback loop is very short and allows the team to present something to the customer much sooner and with much less time, energy and money invested to find out if they are going down the right path. Frequent inspection of the product and solicitation of feedback is key here as it is much easier to affect change early than late in development. There is still a plan but it is more flexible and able to adapt.
Along with the manifesto they put together 12 principles of Agile that are distilled into the manifesto. I will cover these in the next post.
Let's look at these individually. The first is Individuals and Interactions over processes and tools. What they are saying is that in order to effectively collaborate and meet the customer's needs, we need to interact with others in a positive way. The idea is that we shouldn't get hung up on the processes and tools to be used, rather talk to people and value their input. Diverse viewpoints help to strengthen a team as long as the teams values the individuals and listens to them.
Working Software over comprehensive documentation. Here they are saying that the focus on the team should be to create working software without getting hung up on documenting everything. That's not to say that some documentation isn't important, just that the working final product is more valuable than volumes of documentation. The documentation should be enough to explain the logic and choices so that a future team needing to revise the software can easily understand the choices made.
Customer collaboration over contract negotiation. This one is a little trickier as it values working with the customer and getting their input as the software is created. The idea is to not have to have everything go through lengthy negotiation and formal change orders. That's not to say that some negotiation isn't needed, but that it shouldn't be seen as a battle to be won or lost. The end result should be something that both sides feel good about and that they had input into. Too often the contract negotiations seem to turn the developers and the customer into adversaries instead of allies. It is much easier to work with and ally and value their input than it is to work with someone seen as the enemy.
Responding to change over following a plan. This is a big one that can get out of hand rather quickly. The idea is that we recognize that we know very little about the final product and how to get there at the start of a project. In traditional project management this is when we would lay out the entire plan and then try to stick to it, even though we really didn't have a lot of information as to whether it is right or not. This can result in a lot of wasted time and effort building the wrong thing because you won't know it is the wrong thing until very far down the road. In agile the feedback loop is very short and allows the team to present something to the customer much sooner and with much less time, energy and money invested to find out if they are going down the right path. Frequent inspection of the product and solicitation of feedback is key here as it is much easier to affect change early than late in development. There is still a plan but it is more flexible and able to adapt.
Along with the manifesto they put together 12 principles of Agile that are distilled into the manifesto. I will cover these in the next post.
No comments:
Post a Comment