Agile Manifesto — 4 agile values explained
Developing a product using the right approach doesn’t mean having a successful product. Delivering a successful project by meeting timeline, scope and cost doesn’t guarantee a successful product. Product is successful when it adds value to customers and the organization.
It was not the case in the software industry previously, especially before agile software development. Software development was being done by following a rigid process with having a comprehensive plan. Importance was given to documentation such as requirement documents like SRS, BRD, FSD and also to design documents such as HLD and LLD. Similarly, testing, development, and deployment processes were also heavily documented. Developers cared only about following the contract in the form of business sign-off instead of paying attention to a helpful product.
Traditional processes started slowing down the organization’s ability to respond faster as its complexities kept growing. Expectations and products were failing at a rapid rate, but startups were growing as they were lean. Then in 2001, seventeen software developers came together to discuss possible lightweight methods for software development.
They drafted a manifesto with four values and 12 principles for agile software development. This manifesto is known as the manifesto for agile software development. These values and principles brought tremendous improvements in the software development process. They are now even being followed to develop non-software products, such as machines, motor vehicles, medical devices, food, clothing, music, and various other products.
In this article, I will be discussing the four values written in the agile manifesto.
Individuals and interactions over process and tools
Traditionally project team led by the project manager was paying much attention to the process. The majority of them followed the waterfall project management technique based on the article published in 1970 by Winston Royce. The waterfall method itself was a five-step process as described by him. In 1985, the United States Department of Defense captured this approach in their standards for working with software development contractors, which stated that the contractor should implement a software development cycle that includes the following six phases: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding, and Unit Testing, Integration, and Testing.
Following stringent processes used to make the development process rigid, there wasn’t much scope to adopt changes during the project’s execution. Additionally, a well-defined process is not the answer to every problem but being adaptive to change is. No matter how detailed and well-defined a process is, there will always come some barriers that couldn’t have been anticipated by any process or tool such overcome.
When individuals sit together, discussing possible solutions to a problem that result in a unique approach to solving a complex problem. Innovation doesn’t come from rigid processes, but it does come from experimenting with various techniques. The agile manifesto says that we should focus more on having competent people working together effectively. Processes and tools are not harmful but don’t use them until they make things easy and effective.
Working software over comprehensive documentation
A lot of documentation used to be done before, even before starting to build the software. The features, specifications, layout requirements, test cases, design were documented long before their arrival time. This approach had some drawbacks. Like what you have documented will be outdated by the time you are done with it, you may create many features, which the end-user may never use.
The time spent on the documentation of such features also goes in vain, too much documentation. It also delays the project, which later becomes an opportunity cost for the business. Because of all these drawbacks, the agile manifesto favors working software over comprehensive documents. Instead of wasting a lot of time creating lengthy documents and then taking feedback based on those documents, we should take the feedback based on working software.
Customer collaboration over contract negotiation
In the traditional software development method, the customer was involved only at the beginning of the project for contract negotiation. One more time, if there were any changes to be made in the contract. And finally, at the end of the project, The development process was more focused on what is written in the contract instead of focusing on what the customer wants.
This approach neglected the value of customer feedback during the project. When software is developed without constant feedback, the result is often a product that does not completely satisfy the customers’ needs. That is why the agile manifesto favors customer collaboration over contract negotiation. Agile emphasizes take on constant feedback from the customer throughout the development process.
So whatever is being developed is also being seen by the customer. Whenever the customer feels that the project is going in the wrong direction, they can steer the project by providing inputs to the developers.
Responding to change over following plan
We’re not in favor of the change was very much a usual statement in the traditional project management approach. The waterfall approach was to create detailed plans in the beginning and then following them through the project. Being rigid leads to creating an improper product, but it also makes us miss the chances of bringing changes that could cause our product better.
That is why the agile manifesto favors responding to change over following plans. When software is developed with agility, we start with a plan that gives us enough idea of the direction we want to move. Then as we proceed and seeing new events unfolding in front of us, We incorporate those realities into the ongoing work.
So these were the four values of the agile manifesto. Follow them in your project management to ensure its success. Don’t forget to write your feedback.
