It’s Time to Put an End to the Discussion, Are You Really Agile?

The objective of this article is to put an end, once and for all, to all the questions and confusion related to agility in software development. So, let’s begin with the basics, the meaning of ‘agile’.

What Does the Word ‘Agile’ Mean?

Let’s start with the following statement, of my authoring:

“Being agile is a quality, an objective you are trying to achieve.”

Understood? You may get it on some level, but it’s not so easy to truly understand the phrase. When truly studied, the definition becomes too abstract, so I would expect the most honest answer would be “no!”’ or “not completely”. 

It’s best to divide the phrase for better comprehension. If we look up the word ‘quality’ in the dictionary, we will find answers such as the following:

• A permanent or distinctive trait of the essence of a person or thing / A characteristic or a trait of a person or object

Ok, we see that a ‘quality’ is a characteristic or a trait, something that sets us apart. But let’s keep going. If we look up the word ‘agile’ (without any context related to project management), we find definitions such as:

• The ability to react quickly with adequate movements when facing changing situations.

Right, now we can start to broaden the phrase and say that being agile means possessing the permanent trait of being able to react quickly to changing situations. It is an objective because it’s not an ability we always possess, so it implies constant work and improvement over time.

Got it. But What About When it Comes to Project Management?

In essence, it’s fundamentally the same thing we just defined, having the ability to react appropriately to change. In agile development, we assume there will always be uncertainty and this is overcome through iterations, anticipation, and adaptation. But this ability requires a certain way of thinking as well as a way of working that must be applied to achieve the best results. Therefore, it’s important to explain its inception.

Agile methodology was ‘officially’ born in February 2011, when 17 leaders in computer science and management (later known as the Agile Alliance) gathered in Snowbird, Utah (at a ski resort) with the intention of finding a way to develop projects based more on trust, respect, and collaboration. As a result, the symbolic ‘Manifesto for Agile Software Development’ was created. The 4 pillars of agile development were defined in this manifesto as well as the 12 principles derived from these pillars (https://agilemanifesto.org/). We won’t go into detail regarding the 12 principles but we will mention them alongside the key pillars to enhance our explanation. The 4 main pillars or aspects 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.

These are the foundations, literally; the whole of agile development expands in a way that is supported by these 4 pillars and that can be brought together in 3 short explanations:

Collaboration and Interactions

One of the most important factors for success in agile methodology is the human factor. This includes not just the actors themselves, but the interactions that take place between them as well. This, in turn, can be observed along two lines of communication that must not fail:

The first line is the communication of the work team with the clients or stakeholders. This must be continuous; if long stretches of time with no feedback are allowed to pass or if the team doesn’t look to the client when they have questions and vice versa, the project is doomed to failure.

The second line is the synergy of the team itself, a good team must be self-organized and motivated. This implies trusting that the work team has sufficient ability to carry out an assigned task because they know how to maximize their work and avoid rework. They are able to create solution architecture in the right way with a clear vision of the requirements. A high-performance team is always looking for constant improvement.

The above can be mapped with agile principles 4, 5, 6, 9, 10, 11, and 12.

Functional and Iterative Software

The fundamental idea behind agile development is being able to deliver value from the earliest stages of a project (a differentiating factor when compared to traditional development). This goes hand in hand with the concept of continuous delivery. As we explained in the previous paragraph, there has to be continuous feedback and communication with the client, but how do we guarantee this feedback? We guarantee it by providing real value with software (in our case) that the client can use. It’s important to clarify that people confuse this principle and think that each iteration must be a deliverable for the client, especially when applying a development framework (Scrum, XP, etc.) and this is not necessarily correct.

Providing value means clearly knowing when we are going to deliver, not just simply delivering what we’ve developed so far. The latter can have negative effects, particularly when providing the client with many deliveries that end up being ‘the same thing’ in their perspective. The work may not be apparent to the client and they could stop caring about the process. Remember:  only deliver when there’s real value for the client!

Agile is iterative and incremental because, in effect, we will be making improvements with each cycle and we need valuable feedback from the stakeholders. This is one of the strengths of agile development when compared to other methodologies. 

The above can be mapped with agile principles 1,3, 7, and 8.

Responding to Change

One of the major problems with traditional methodologies was that considerable time was spent analyzing the system, then creating heavy documents with all the requirements, which were passed on to a team that, in their own isolated world, developed everything in those documents on a very static timeline. But did it work? Most of the time, no, it didn’t.

It’s not always possible to know everything that will be required from a software, especially not at the start of a project. This traditional methodology greatly limited the client, who would end up creating requirements without depth, resulting in a system that couldn’t really be used. Agile then appeared and stated: ‘change, we accept you. You are real and we cannot live without you.’ When it comes to agile methodology, it’s important to know what the final purpose of the project is but it’s not necessary to know the complete depth of the software’s features.

Each iteration, each increment, each bit of feedback brings with it the opportunity to reformulate. It sounds exhausting, but the real benefit is the opportunity to identify change early on (when it comes to software projects, the sooner you do this, the better). This also applies to identifying risks and opportunities; it’s very probable that risks will come up during iterations - as opposed to the start of the project when the panorama is just too vast. This is where the ‘Cone of Uncertainty’ comes into play:

From the above figure, we can see that at the start of a software project, variability or uncertainty can be very high. As time progresses and the project is defined in detail, this variability decreases, which means that it’s (very) likely that an estimation made at the beginning will turn out to be wrong. Even when you have the detailed designs of all the requirements, projects still have minimal variability (another interesting topic related to ROM: Rough Order of Magnitude Estimate). Agile methodology acknowledges this and says: ‘welcome!’.

This can be mapped with agile principle 2, but it indirectly includes all other principles: you need a team that knows how to manage every change, that can communicate each risk or change in a crystal clear manner to the client, and that delivers constant value so as to reduce variability.

Let’s Get it Straight

We will clarify certain key points so as to put an end to many discussions:

• Agility is to deliver VALUE promptly and constantly.
• Agility does not tell us HOW to do things, it tells us WHAT must be in place for things to work. It’s a philosophy, a way of thinking, and it includes many frameworks.
• Frameworks such as SCRUM, XP, and Kanban take the WHAT and say: ‘alright, we’ll do it this way’ (the HOW).
• ‘Individuals and interactions over processes and tools’ does not mean there are no tools or processes. These are still defined and necessary. Even SCRUM, for example, uses 19 processes. Although you may have the best tools and processes, if interactions are not working out or if individuals don’t connect, all else counts for nothing. 
• Working software over comprehensive documentation. Once more, documentation will always exist; for example, requirements must be written out in detail to avoid any confusion. But we must remember, agility values value and many documents don’t really provide any value. You must keep this in mind at all moments.
• Customer collaboration over contract negotiation. Contracts are indispensable and must be very clear. But this pillar implies it’s better to talk and collaborate with the client than end up looking for contractual clauses.
• ‘Responding to change over following a plan’ does not mean that an initial plan doesn’t exist. Every project needs a plan, even if it’s just a rough one, and this needs to be refined over time. But it’s important to know that changes will happen and that these need to be managed.
• Agility does not mean you accept ALL proposed changes. All changes must be managed accordingly while always understanding the VALUE they may contribute to a project. 
• An iteration is not the same thing as a release. Tools such as a release calendar should be used and deliveries made only when they provide real value to the client.

What Does Being Agile Mean?

Well, after all these explanations, we now have a shorter and more complete definition:

“Being agile is the ability to create and respond to change in a way that always provides VALUE to a project.”

And to achieve this, we need:

• Good internal and external communication.
• To deliver value promptly and continuously
• A self-organized team
• To understand that change happens and if we want to achieve success, we must accept it.