Monday, December 4, 2017

The Agile Manifesto - 4 Agile Values Explained | Supreme Agile

תוצאת תמונה עבור ‪agile values‬‏
The agile software development approach was created back then in 2001 with the publication of the Agile Manifesto, a document containing the principles and overall spirit of this new approach. The agile manifesto contains four main principles that are used to this day in any software development process that based on one of the agile methodologies (Scrum, Kanban, Extreme Programming (ET) Etc.).

The four principles are:
  1. Individuals and Interactions more than processes and tools
  2. Working Software more than comprehensive documentation
  3. Customer Collaboration more than contract negotiation
  4. Responding to Change more than following a plan
By creating these principles, the creators determined the although the values located on the right are very important, we still need to prefer the values from the left. Now, a very important thing that we must raise, is that this approach is relevant only in case of conflicts that may arise during the project. 

In this article, we will try to understand the logic behind each one of these principles:

Individuals and Interactions more than processes and tools

In order to promote a project, the stakeholders must use a dedicated and specific process and management/Development tools that will help them to accomplish the project goals. 

That's just a simple fact that we cannot deny.  However, the agile approach reminds us that there some aspects that even more important such as face to face communication, Trust among the relevant stakeholders, Self-Organized teams and more. 

Without these basic aspects, we will most likely fail to promote the project agenda that based on human resources, regarding the quality of the process and tools used on the way. 

Working Software more than Comprehensive Documentation

The traditional software development methodologies are built on the belief that there is a need in heavy detailed documentation process to handle each phase of the project. This could be fine and appreciated, but the biggest problem occurs once the documentation becomes the main goal of the team instead of focusing on delivering a working product.

The value of a "Working Software" is one of the most important concepts in agile, and therefore it gets a Hugh focus throughout the agile process. 

The main example that demonstrates this issue, is the concept of providing an increment software release in a very short development cycles (2-4 weeks) without the need to invest a major effort to document every step in the way that leads to it.

Customer Collaboration more than contract negotiation

To achieve success in almost any field, we first need to understand the expectations of the other side, this is the same thing in software development process, where we need to collect the customer requirements (Expectations) that are used as the baseline for the future development process. In traditional software development methodologies, those requirements are defined at the start of the project subject to the contract signed between the customer and the company. 

Sounds good, but what happens if the customer needs to change the preliminary requirements once he realizes that there is a gap between the original requirements and his current needs? Well, this is the problem! Due to the original contract signed between the two sides, each modification in requirements will resolve a contract modification, that in most cases will be denied by the company and will not allow the customer to get the product he really needs.

In agile, we still use contacts, but with one major difference, now the contracts are signed with the purpose to work with the customer and based on a collaborative communication that will allow the customer to modify the preliminary requirements without the restrictions as we saw in traditional models.

Responding to Change more than following a plan

In the traditional software development methodologies, we had clear phases that include a massive amount of planning that we will use for the entire lifecycle of the project. If we look at the "Waterfall" methodology that is probably the most commonly used in companies that are not using agile frameworks, we will see that there are five phases (Requirements -> Design -> Implementation -> Verification -> Maintenance), that are used during the SDLC.

Now, although each phase makes sense in the SDLC, there are some major problems that are driven by the nature of these models, Examples: 

1.   There is no option for to start a next without fully completing the previous one.
2.    There is a Hugh amount of planning per phase.
3.    There is almost zero tolerance to absorb modifications in project requirements.

So, what is so different in agile? The main thing is the understanding that ongoing changes in requirements are just another way to allow the customer to get the product that he really needs, therefore, the spirit of agile is to accept and embrace the ongoing requirements and the deep understanding that this is the best way to provide the best and most suitable product for the customer. 

The true agile spirit is based on the capability to flow with ongoing changes and not blocking them, by following this spirit, we will allow the organization to achieve some Hugh advantages that will provide a solid ground for greater collaboration with the customer.  

No comments:

Post a Comment

My Presentations