Introduction to Agile Software Development | David Tzemach
Updated: Jan 25, 2022
This article provides an overview of Agile and illustrates the differences between Agile software development and traditional methodologies (e.g., waterfall and V-model).
A Short History of Agile
This entire blog is dedicated to quality in the world of Agile software development. Therefore, it is good to start with a short description of Agile and its history.
Dictionary definitions of agile:
Ag·ile - adj.
Characterized by quickness, lightness, and ease of movement; nimble.
Mentally quick or alert: an agile mind.
The word agile describes characteristics usually related to animals and people. So, when did the term become relevant to the software development industry?
It started back in February 2001, when a group of 17 experts in the field of software development frameworks (including Kent Beck, Mike Beedle, Robert C. "Uncle Bob" Martin, and others) met at the Summit Lodge in Utah's Snowbird ski resort. Their primary mission was to find an alternative methodology for developing products due to frustration with the traditional methodologies since the early 1970s.
These traditional models, led by the waterfall model, had contributed significantly to the software industry. However, in the 1990s, these methodologies were no longer suitable due to the increasing demand for speed and high-quality delivery and the ability to adjust development to meet actual customers' needs.
Although the mission was clear and accepted by all participants, it was still almost impossible for all 17 people to agree on a single solution. However, the group did agree on four values and twelve supporting principles known as the Agile Manifesto.
The Core Values of the Agile Manifesto
The Agile Manifesto contains four central values used today as the basis of the Agile framework.
The four values are:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer Collaboration Over Contract Negotiation
Responding to Change Over Following a plan
Although the values on the left (in bold) are very important, we still need the values on the right. When there is a conflict between the values, the values on the left (in bold) take precedence.
Value 1: Individuals and interactions over processes and tools
To promote a project, stakeholders must use specific, reliable methods and management and development tools to accomplish their project goals.
This principle reminds us that face-to-face communication with relevant stakeholders is imperative, as with self-organized teams. No tools or methods will succeed in the Agile environment without these in place, irrespective of how good they are.
Value 2: Working software over comprehensive documentation
Traditional software development methodologies were built on a detailed documentation process at each development life cycle phase. This may sound like a good idea. However, if the documentation becomes the team's main goal, it can become a bottleneck, taking focus away from delivering working software.
The working software principle is one of the essential concepts in Agile; therefore, it receives center-stage throughout the Agile process. Incremental software improvements are released in short cycles (2-4 weeks). It is done without investing lots of effort in documenting every aspect of building the software (LLDs, SRSs, STPs, etc.).
Value 3: Customer collaboration over contract negotiation
In software development, as in other industries, we want to collect the customer's requirements or expectations, which will be used as a baseline for development. In traditional software development methodologies, these requirements are defined at the beginning of the project via a contract signed between the customer and the software development company.
Sounds great, but what happens if the customer needs to change the preliminary requirements once she realizes a gap between the original requirements and her current needs? Well, this is the problem! Due to the existing contract signed between the two parties, each modification in the requirements results in the agreement being updated.
Modifications to a customer contract are often denied by the software development company, resulting in the customer getting a product she doesn't want.
In Agile, we also use contracts, but with a significant difference. Contracts are signed to work with the customer; based on collaborative communication, they allow the customer to modify her requirements (within reason) without the restrictions inherent in traditional models.
Value 4: Responding to change over following a plan
In traditional software development methodologies, clearly defined phases include massive planning used for the entire project's lifecycle. Probably the most commonly used methodology in companies that don't use Agile frameworks is the waterfall methodology. The software development life cycle (SDLC) has five phases: requirements, design, implementation, verification, and maintenance.
Although each phase on its own makes sense, this methodology poses significant problems, namely:
There is no option to start a phase without fully completing the previous one.
A large amount of planning is necessary per phase.
There is almost zero tolerance to modifications in project requirements (especially during later stages).
Any modification in requirements adds significant risks and costs to the project.
So, what is so different in Agile? The main difference is that there are continuous changes and refinement of requirements, which ultimately assist the customer in receiving the product she truly needs.
The Agile mindset of accepting and embracing ongoing changes is different from traditional development methods. It provides the most suitable product for the customer.
Once adopted as a mindset, Agile can be a game-changer within an organization. It can lead to higher quality products delivered to target customers, reduce software failures, improve the development life cycle efficiency, and provide better value to the customer.