17 people assembled at Saltlake city, Utah, USA In 2001 February 11-13, with an objective of coming up with an alternate approach to document driven, heavy weight process based software development method which at that time was waterfall. Waterfall is not a wrong method but there are certain challenges such as value delivery is delayed, less flexible to make scope changes late, customer cannot get return on investment until the end delivery, last minute surprises etc. So they have come up with Agile Manifesto which has 4 Values and 12 Principles. This will help teams to deliver software iteratively and incrementally with a mindset of open to change at any time. In this article, we will discuss the 4 Agile Values given in “Agile Manifesto”. Here is the extract from the www.agilemanifesto.org website of the 4 values.
It starts with “we are uncovering better ways…..”, which means bringing something into light which was hidden so far. The 4 statements in the center of the above image are the 4 agile values.
1.Individuals and interactions OVER processes and tools:
Most of the time, processes beat common sense.
– Suppose you have a technically very strong team but they do not work as a team. They have egos and reservations. But you have great processes and tools. Will it work to deliver software successfully? No, it won’t.
– Let’s say, you have technically a mix of excellent and good skills and with a good team culture and they help each other very well, BUT, you have limited tools and processes available. Will it work? OF course, because people can make tools and processes. Processes and tools do not build software, people build software.
– Assume that you have an excellent documentation process in place and you received a detailed requirements specification document. Will it guarantee that the requirement is understood properly, and you can convert it into a working software? May not be always, this will lead to less interaction and more assumptions based delivery.
– So people and how they communicate is more valuable than what processes and tools they use
2. Working software OVER comprehensive documentation:
– Assume that you have a complete set of requirements defined upfront and in very detailed. Will that add any value to the customer? No, it may help your team while building the project
– Can that guarantee that requirements will not change? Not really
– Assume that you have a great and in depth technical design and architecture documentation and also the database design in place. Does it help the customer to get some revenue? No, this documentation is for your team to work on the project
– Instead, you create a bunch of features that are important, valuable and urgent to the customer in the form of usable product increment. This can be used by the customer to address his problem and fulfill the need
– “I know when I see it” this is true in most of the cases. So, customers will know better what they want by seeing a working software. But not a well-defined documentation
– It does not mean that documentation does not have any value. The second value in the Agile Manifesto tells that the teams should shift their focus from the upfront comprehensive documentation to creating working software. In addition that any documentation that is useful and required by the customer and the teams, you can create
3. Customer collaboration OVER contract negotiation:
Contract based working leads to “competing” environment. Because contracts are created due to lack of trust between the customer and vendor.
– For example, You have a clearly defined scope and a well-defined contract (agreement) between the customer and you. Does it help the customer to have flexibility of changing the scope in between? No, you will not allow, showing the contact as a reason.
– Instead, you have your customer working with you closely and provide you the requirements face to face and you can prioritize them to be delivered as working software. Does it have any advantages over the previous scenario?
– Bringing customers and your team to the same level of understanding will increase the transparency and trust so the software development will become more effective.
4. Responding to change OVER following a plan:
– Planning is everything and plans are nothing
– Assume that you have a well-defined start to end plan in Microsoft project. Does it guarantee that there will be no change? No!
– Instead, if you plan for a short duration with what you know and keep flexibility of changing it based on what the customer wants, will it add value? Of course, yes.
– So keeping the planning continuous with an open mind to respond to changes based on the value those changes bring to the Product is the idea behind this value.
Conclusion: These 4 values have two parts separated by a word “OVER”. The right side phrases have value but we value the left side phrases which helps us to be agile. Shifting from the right side phrases to the left side phrases is part of Agile transformation in the organizations. All the teams, not only engineering teams, including support teams such as HR, Finance, Admin, Facilities, IT teams have to understand these values and change their work according to these 4 values so that organization can see better productivity, higher transparency, reduced time to market and most importantly, higher customer satisfaction.