Agile software development is on great advance, more and more software teams adopting it. But what is it exactly?
It’s a development approach, where the entire process – from planning to requirements analysis and design to the programming, test and deployment run through several repeating short cycles (iterations), auto-adapting themselves.
It’s a set of best practices (not a formal process) with roots in many modern management approaches as the lean manufacturing (famously introduced at Toyota), the evolutionary system (Evo) from Tom Gilb, Scrum and the Extreme Programming, and partly a reaction from the heavily regulated waterfall model (http://en.wikipedia.org/wiki/Waterfall_model).
A turning point happened in February 2001, when prominent members of the “lightweight methods” community met and created the Agile Manifesto and later founded the Agile Alliance. The name agile was also coined at that meeting.
As you can see on the site the manifesto lists a series of value (on the left) preferred over related commonly used values (on the right). Before we look into the details, a very important note from the Manifesto:
“That is, while there is value in the items on the right, we value the items on the left more.”
The manifesto says that they value:
Individuals and interactions over processes and tools
Projects are built around individuals. People are the most important variable in a project and this should not be forget.
Interaction refers to the communication in the team and among the stakeholders; agile methods always push to foster communication at any level and time. In concret: if you have doubts or questions, ask directly your colleagues and the project stakeholders, don’t just rely on the process steps or the tools.
Working software over comprehensive documentation
As you say: “if the territory and the map disagree, trust the territory”.
Working software is the principal measure of progress, despite what a project plan or a design document can say, only it can really tell you where you are with the project.
This is also why agile methods favour frequent software deliveries.
Customer collaboration over contract negotiation
Responding to change over following a plan
A project is there because someone sponsored and founded it. Every project has one or more customers who have the final word about whether was successful or not. This is so critical that most models, as the waterfall one, are investing a big amount of the project life into defining, assessing and documenting the requirements, producing at the end a formal negotiated contract.
This is working fine if:
1. the requirements, the customers and the business scenario are not changing for the entire project life.
2. the requirements are well understood.
I can’t think of very few projects where these are true.
The agile answer to that is to allow requirements to change, even late in the process and to have a daily cooperation with the customers, also after the initial requirements definition phase.
Having frequent software deliveries is also part of the effort to satisfy customers first of all.
Next: the problem with the waterfall method