It was the year 2001, when in Utah, 17 software developers met up and created the agile manifesto (http://agilemanifesto.org/). It was a collection of values and principles, shared amongst people who were inspired by the idea of a better, more effective way of software development. The manifesto formed the basis for several Agile methodologies that evolved in the years to come.
The Agile methodologies, were seen as an answer to several shortcomings of the classic Waterfall model. While the initial idea was limited to merely providing a new way of approaching software development, today, Agile methodologies involve teams and project management as well.
The core values
The Agile manifesto is built upon four core values. While these values seem to be generic and hard to grasp we will attempt to shed some light on them. As the manifesto says:
That is, while there is value in the items on
the right, we value the items on the left more.
Individuals and interactions over processes and tools
What this value means is that at the end of the day, it is people who deliver the final product. People form teams. Depending on the size of the team ,various roles can co-exist and collaborate. Developers, project managers, customers, testers and so on. It is true that new, effective tools are constantly developed and are made available to the team . And sometimes, meetings after meetings are spent only to fine tune the processes. These are all important, but we must never forget that people and the level of communication between them plays a crucial role in delivering the best results. It is better for a company to invest in people first before moving to the processes and tools.
Working software over comprehensive documentation
On many occasions, the teams find themselves trapped in an infinite loop of over-documenting. Countless pages and diagrams full of requirements, trying to do the (almost) impossible.
To document every single part of the product to be delivered. The customer is asked for their requirements, covering every edge case and scenario. What experience has taught is that it is very hard to visualise the whole product beforehand and also, requirements might change. Agile methodologies encourage the constant delivery of working software in an incremental way. That is, small “chunks” of the product, where each one of them is fully working as a standalone piece. Documentation is necessary, but not the priority.
Customer collaboration over contract negotiation
Lets get something straight. Contracts are important, there can be no business without a contract. However, there must be some kind of flexibility. As mentioned previously, it is highly possible that the customer might change their minds, or that an early stage they are not, even themselves 100% sure of what exactly they want. It could be the case that they are not tech savvy. Either way, it is important to make them feel safe, that they are the ones who decide, and if they change their mind about a requirement, it is never too late. But, for this to happen constant interaction and collaboration is needed, otherwise, we might find ourselves in the wrong path, and it would take a great amount of work to get back on the right track.
Responding to change over following a plan
Inevitably, many things can change. Customer requirements, the customer understanding of the project, technology, even priorities within the same project could change over time. Having a plan is necessary, but the plan must not be restrictive. Again, the notion of flexibility is a key here. Having a very detailed and strict plan might be proven cumbersome. Agile methodologies encourage the teams to leave room for change. The driving force must be the changing requirements and not the initial plan.