In this article, let us look at how Agile has transformed over the years – its history, its core values, and principles, the myths around Agile, the big “NO”s in Agile software development, and how Agile looks going forward.

HISTORY

Agile Methodology is derived from the lightweight software development methods that were being practiced in the 1990s. These lightweight software development methods include Scrum, Crystal Clear, and feature-driven development among others. In the year 2001, seventeen developers met at Utah and discussed the lightweight software development methods. As a result, they published the “Manifesto for Agile Software Development”.

In the VUCA (Volatile, Uncertain, Complex, Ambiguous) world, it is expected that the requirements are volatile and technology is uncertain. According to Stacey matrix (the diagram featured in the post), the zone where the unknown is more than the known is called a complex zone. And, Agile fits well in a complex zone. When the unknown is more than the known, Agile is best suited for software development.

VALUES AND PRINCIPLES

Agile is based on four values and twelve principles. Let us look at what the Agile manifesto says.

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”

Contrary to the popular belief, it doesn’t mean that the items on the right need to be ignored. It simply implies that the items on the left should be valued more than the ones on the right. The twelve principles of Agile can be found in Agile Manifesto. The objective of these 12 principles is to build a winning team and a winning product.

MYTHS

In the course of the adoption of Agile methodology, certain myths were formed.

Agile is Scrum
While Agile is an approach to build software in a complex environment, Scrum is a framework for following the Agile methodology. A framework is a set of rules and guidelines that can be facilitated by different tools, techniques, and strategies. While there are a lot of frameworks, Scrum is the most commonly used. The scrum development team consists of the developers, product owner, and scrum master. These roles are defined in Scrum and not in Agile.

Agile is free of documentation
The Agile manifesto says that the working software is preferred over comprehensive documentation. At the same time, documentation can help the stakeholders to understand how the software is built and how to use/modify the pieces of software. Hence, documentation should be value-driven instead of effort-driven. It is not necessary to prepare the document in a traditional word/PDF format. The developer can simply record a video in place of a text document for the sake of convenience. The outcome is what matters and not the tool to produce the outcome.

Agile is about answering the three questions
As Agile is iterative and incremental development, it needs frequent retrospection on the developing software. Hence, a method such as a stand-up meeting is preferred, where the team members gather to discuss the progress of the working software.
              What you did yesterday?
              What do you do today?
              What are the challenges?
The above three questions can be quite irritating for software developers because of the format in which they are posted. If we rephrase these questions as below, it would make more sense.
              Where are we now in achieving the goal?
              Are we progressing in the right direction?
              Do we see any challenges in reaching the goal?
Development teams mistakenly believe it to be a status meeting. Instead, it should be considered an inspect and adapt meeting to take effective decisions on time.

STRICT “NO”s IN AGILE SOFTWARE DEVELOPMENT

The below practices followed in the Agile software development can be serious hindrances in building a winning product.

Problem Solving during stand-up meeting
The purpose of a stand-up meeting is to understand whether the team heads in the right direction and whether there are any challenges ahead. The meeting should be ideally not more than 15 minutes. If the members start discussing the technical challenges during the stand-up meeting, the core purpose would be lost and it would waste the time of the other members who are least likely to be involved in solving the technical challenge. A separate meeting post the stand-up meeting is preferred to discuss the technical challenges with the respective stakeholders.

Assigning tasks to the team members
Agile says in one of the principles that the best architectures, requirements, and designs emerge from the self-organizing teams. In an Agile environment, team members are expected to collaborate, discuss, and choose their tasks instead of being directed by a manager. Choosing the own tasks brings a sense of ownership to the individuals and also enhances the teamwork.

Fixed scope, time, quality, and cost
In a complex environment, it is difficult to keep all the parameters fixed. Hence, at least one of the parameters among scope, time, quality, and cost should be variable. When all are kept fixed, developers would burn out quickly and it is definitely not a good practice to follow.

Skipping the sprint review and sprint retrospection meetings
This is specific to the Scrum framework. It quite happens that the teams plan the sprint, work on it, and close the sprint without formal review and retrospection meeting to focus on the continual improvement. The team should conduct a review meeting to inspect and adapt the product and a retrospection meeting to inspect and adapt the process practiced in the sprint cycle.

THE MODERN AGILE

We conventionally tend to believe that Agile applies only to the software industry. However, in reality, Agile can be expanded to many other industries. ScrumAlliance has launched a new portal called AgileMatters where you can find a series of articles about Agile Education, Agile Leadership, Agile Innovation, Agile Teams, Agile Outside IT, and so on. From the AgileMatters, I came across two brilliant articles where the agile principles are applied in sales (Agile in Sales) and healthcare (Agile in Healthcare) departments. You can read how agile principles are tailored to sales departments and how agile values are practiced in the healthcare industry.

Agile, when used effectively, is a great approach to build great products. All it needs is consistent support from the top leadership to allow the development teams to function with minimal governance. The benefits of Agile can soon be realized through customer satisfaction.