Introduction and Context
In 2001, a group of 17 developers who already practiced agile methods such as XP, DSDM, SCRUM, FDD, formed the Agile Alliance , which gave birth to the Agile Manifesto. The manifesto presents values and principles that can be followed by people who involved in software development to achieve the ultimate goal of creating good software products.
In this article, I will take you through the four fundamental values mentioned in Agile Manifesto alongside 12 principles of Agile. The Agile manifesto defines values not alternatives, encouraging different roles to focus on certain areas, without eliminating others.
Individuals and Interactions over processes and tools
This is the first value of Agile Manifesto and it emphasises teamwork and communication. For building software solutions, teams of people need to work together effectively through productive interactions.
Tools are important part of software development, but making a great software depends on a lot more on teamwork, regardless of the tools that teams use.
Think of the motto: ” A fool with a tool is still a fool”
I am not saying that the tools are unnecessary. Tools and processes are still fundamental to software development. Without the right tool or process, your team will face difficulties. The point is that the tool must meet the team’s need and process – not the other way around.
Software products are built by people and to do this correctly, everyone needs to work together and should have good communication between all those involved. Not only developers, you need to include QA , UX , project managers, product owners , business analysts , other stake holders , leaders and anyone else involved in the project within the organisation.
Processes and tools are important, but they are irrelevant if the people working on the project cannot work together effectively and maintain effective communication.
Working software over comprehensive documentation
While we are working with more comprehensive software, we will need robust documentation, and we will possibly face it. In such scenarios, we will need to read a hundred pages of product specifications to improve our understanding of the software. This is not wrong, but it should not be the rule of thumb for every project developed…
Documentation definitely has its place and can be a great resource or reference for users or coworkers who are wondering what the software is and / or how it works. Although some projects often need documentation before they even develop the software. These moments are frustrating and, if the company is really agile, it needs to remind its employees of this value: the main objective of software development is to develop software that offers commercial benefits and not extensive documentation.
Take the time to develop software that is clear, self-explanatory and that meets the tasks that users need to perform, instead of investing time creating documents that will be out of date before they are even written.
Customer collaboration over contract negotiation
Only your customers can say what they want and your job is to listen. Successful development teams work closely and communicate with their customers frequently. Of course, they won’t be able to tell you the next innovative idea, but by listening and getting their feedback , you’ll understand what they really want from your product.
Try to create a relationship with customers that encourages communication and learn how they think, their opinions & preferences. This may make your job little more difficult, but inturn will give much better results.
Responding to change over following a plan
After initial planning, your client or business stakeholder might change their mind about what is being built. This can be because you/others gave them new ideas from the software delivered in a previous iteration or it may be because of the change of priorities. Some code can be thrown away and the time & effort put in develop those can be lost. But if you are working with short iterations, the loss is certainly minimised due to possible changes.
There is nothing wrong with having a project plan. In fact we should be concerned with any project that does not have one. However a project plan must be flexible enough to be changed, there must be room to change/improvement as per changes in situations, otherwise your plan will quickly become irrelevant, your processes may no longer be effective and your team may no longer be needed by the customer / stakeholder.
Being willing to accept changes and attentive to respond quickly, will certainly generate more value for the customer.
12 Principles of Agile
Click the download button to download the above slides as PDF.
Not everyone is Agile & not everyone needs to be!!!
The interesting thing about these value statements is that most organisations totally agree with them, but rarely adhere to them coming into practice. A few claim that creating software is their fundamental business objective, but will insist to spend months on creating documentations.
Just keep in mind the ultimate goal of your project and if you are forced to do something that deviates from that goal, bring it to your team and remind them on these values & principles.
A true agile team is one where the members, in addition to criticising the project or the process, are willing to listen and to suggest improvements
Stay tuned for more about Agile & what is agile for testers…
References:
https://www.agilealliance.org/agile101/the-agile-manifesto/
Leave a Reply