The Agile Objective

if you don’t know where you are going, any road will take you there (Lewis Carroll)

I believe the objective of Agile (or the objective of using the Agile approach to software development) is “being able to deliver customer value sustainably, with the required quality and in a changing environment”

Does the Agile Manifesto says this?

I believe it doesn’t, explicitly. However, aligning to the values and principles here stated leads to approaches to software development that have the customer needs as its main objectives. The Agile Manifesto is so value oriented that “uncovering better ways of developing software” means (to me) “uncovering better ways of delivering the value that customers need” (probably I read it this way because I am a software developer and delivering software is the only means that I have to provide value to them)

As I read the values again:

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

I become more and more convinced that everything points to delivering value. The first principle says processes and tools are a means to an end, not the objective. The objective is to deliver value. Documentation is not the objective. The objective is to provide software that brings value. Collaborating with the customers to build what the customers wants is more important that telling them that they didn’t know what they want. And building what the customer wants at that moment will deliver more and better value than building what the customer originally planned.

Following the principles and values, we build software:

• that contains the features that the customers are looking for
• where the most important features are delivered early, to make our customer competitive and to solve their problems faster
• that adapts as the business circumstances change
• and that contains the required quality that allows the product to deliver value

As a conclusion, the Agile Manifesto didn’t set an objective but it did set a direction and it also set the bases for a definition of building software focused on delivering value. Not focused on technology (our focus, geeks) or plans (project manager’s focus) but on customer’s needs. The objective (at least what I understand as the objective) is a direct consequence of following these values and principles.

Going back to my definition...

I mentioned the words “sustainably”, with the “required quality” and “in a changing environment”. I will try to explain why these words are in my definition.

There’s a common misconception, usually among people that are just starting with Agile, who believe that Agile means just throwing some code out there fast, without having to think about the design and without having to maintain any documentation. I believe this misconception should be addressed as soon as possible: in the definition of the objective. Having to think about sustainability since the beginning, forces you to think about keeping the cost of change low, which forces you to think about automation and maintaining the code base in a good state. The technical leg of Agile is very important in supporting sustainability because we should be able to deliver value to our customers for as long as they need, without having to be more and more expensive.

With the required quality... That is arguably part of the objective. Some might say that if the software doesn’t have the required quality, it won’t deliver the required value. As you probably know, quality can be divided into external quality “extrinsic, as perceived by the final user” and internal quality or technical quality which allows the product to be reliable, adaptable and ultimately to deliver sustainable value. So which is the required quality? It is the quality deemed to be enough by the Product Owner to deliver the value it needs in the market plus the quality needed by the technical team to being able to keep delivering value.

Finally, in a changing environment. And the business world is a changing environment after all, right?. Who has time to freeze the requirements for a year and be competitive at the same time? It seems to me that Waterfall always pointed to a different direction than business (This may be the reason of so much failure in our field?). Agile is designed to fit in changing environments. And of course, it works better than Waterfall in changing environments. It is one of its distinctive characteristics. Our process and our technical practices should be thought out to make us competitive, to be able to adapt by producing adaptable and reliable software.