Agile Methodology

Agile is a group of methodologies used in project management. It is being used in many companies at the moment, but this was not always the case. Rather, it was only created and introduced in 2001. Why is this the case? Why was it not introduced before? Well, to answer that we have to understand the project management style that was being used previously and why people started to change their approach to project management.

Pre-2001, the main project management style was called the waterfall method. This is how the waterfall method works:

1. Requirement gathering

2. Software design

3. Implementation

4. Verification

5. Maintenance

It only has 5 steps, however, the implementation of these 5 steps would take up to multiple months and any change in the requirements set by the customer would delay the project by months and some were not possible as the program has already been created. The customer would end up getting his product as one big package, hence it was also called "monolithic".

Now, during the technological boom of the 1990s, many companies were asking for programs to be developed, however, they would change the requirements they need day-by-day and this caused the software engineers a large headache as they already created parts of the program, and to add in the new features would mean they would have to change the already completed parts of their code. In a project management style where everything happens like a conveyor belt, from start to finish in one smooth motion, having a change introduced causes multiple problems.

To counteract that, 17 people met in 2001 to discuss how the current methods and procedures are viable but not optimal for software engineers. During the meeting, the manifesto for agile software development was created. There are four main principles that the manifesto outlined, being:

1. Individuals and interactions over processes and tools.

2. Working software over comprehensive documentation.

3. Customer collaboration over contract negotiation.

4. Responding to change over following a plan.

What these four main principles outline is that while there are values in the items on the right, the items on the left are more important. With the introduction of the above principles, the software development lifecycle also changed, from like a conveyor belt where the product is returned after it is made, to iterations that show the end user what is currently developed and incorporate customer feedback into each interation. The agile methodology focuses more on completing parts of the program quickly and shipping it for the customer to see, so we can get feedback and incorporate it into the program before shipping it to them again.

Individuals and interactions over processes and tools

Before the introduction of the agile methodology, the waterfall method highlighted the need for processes and tools. What I mean by this is that once the requirement gathering was done, that meant that the business logic was now known by the development team and they would start their processes in creating the software and designing the tools that they were using. Now, with the introduction of the agile project management style, after each iteration, the project manager would show the end user what is currently made, and instead of sticking to the process such as the waterfall method, we now ask for feedback from the end user so we can create a more suitable application for them.

Working software over comprehensive documentation

In the waterfall method, as change was not frequently introduced in the creation of the program, software engineers would create documentation about everything they made. This is because they only had to follow the business logic that was introduced in the requirement gathering process. This meant that each step was heavily documented, however, that would not be possible if they had to keep changing what they were creating.

Agile is all about responding to change and collaborating with the end users. If the software engineers kept creating comprehensive documentation every time they changed the features, it would take up too much time. Rather, what the Agile Manifesto outlines is that it is better to create the software with working functionality that is suited to the end user and create the documentation afterward. It is more important to have a piece of working software that the end user is happy with than to create a piece of working software that does not fit the end user's intent but has a lot of documentation.

Customer collaboration over contract negotiation

As agile is large on working with the customer, if every time they asked for a change we had to charge them, it would turn the relationship between the software development team and the customer sour as the final bill would be large. Rather, instead of fixating on the monetary issues, it is more beneficial if we are to focus on working together with the customer to create a tailor-made program for them. As long as the change is not too major, as in they don't want to upscale the entire program and perhaps want a "search" function added, the outcome for both sides would be better if we collaborated with the customer and added the feature.

Responding to change over following a plan

The reason Agile was created and introduced was that following a plan was not the most efficient method as customers kept changing what they needed to be created. When change was introduced prior to agile, it would catch the whole team off-guard and would delay the project by months. With the agile methodology, teams now work in a process that is less about following the plan, rather more about being able to incorporate changes that the customer wants into the software. This is done in multiple ways, such as scrums and kanban boards.

Bringing it together

When we combine the main principles of the agile manifesto, we now have a project management style that is much more flexible in responding to changes and creates a program that is more tailored towards the customer's needs. Rather than before where the customer only got to see the end product when the program was completed, now the customer sees the program in iterations, where each iteration is usually completed after a main functionality is completed. After seeing the functionality, the customer can ask for a change that is more suitable for them and the project manager can take it back to the software development team for them to incorporate.