The most important reason why Agile software development methodology can produce successful outcomes

It is because successful outcomes is not the end goal but rather a by-product of the processes of Agile

Let’s begin by defining a successful outcome for a software project.

Some of the commonly used qualitative ways are

• The software does what it was supposed to do
• The software works as per the requirements
• The software solution meets the needs of the client

Some of the well-refined quantitative ways are

• All of the predefined project goals are met
• Each component of the software satisfies the acceptance criteria set for them

These definitions seem alright at first glance, but they are superficial in nature and don’t take into account the intrinsic difference between a software project and a non-software project. A software project results in a software product being created. However it is a fallacy to treat the software product to also be complete when the software project is completed. Once a software product is created it can only be transformed but it should never be treated as complete. This tiny difference in approaching a software project can make a huge difference to one’s definition of a successful outcome for a software project. The definition that I like to go with is

The software is adding value to the business in a tangible manner

The adding value here refers to a host of scenarios which can be quantified in some form and hence tangible - increase in subscribers, savings in time, enhanced productivity , improved efficiency, higher profits i.e. at the end of the day the software is helping the business grow. With this definition, the genuinely successful outcome is when the software is deployed, actively used and tangible results are achieved.

The reality of how a software project plays out is that one truly understands what they need the software to do in order to achieve those tangible results only after they start using the software actively post deployment. This kick-starts the process of constant request for changes and deviating from the initial Software Requirements Specification (SRS), which in itself is not a bad thing, but it can lead to a feeling of having wasted a lot of time on something that was not very useful and hence leads to a general notion of a failed outcome for the project. But the project is not the failure here, it is the approach of the people involved in the project.

In the Agile methodology of developing software (at-least in the one I follow at my firm), it is pertinent to ask the customer (this can be a Product owner, a client, an end-user depending on the context)

Tell me what you want to do with the software, not what you want the software to do

This helps establish the customer goals for their business which will be the underlying goal for the software project. But the successful outcome is treated as unknown as far as the people developing the software are concerned. This is because, no matter how well-intentioned the software team might be to create something useful and valuable, they are not the end-users and hence it is better to accept that fact and not even attempt it. So the main aim of the software team is

• Provide an initial working version of the software in the hands of the customer ASAP, something which can be achieved in 1 ~ 2 months*
• Then keep providing frequent and incremental updates, ideally every fortnight

Now the customer (or product owner or end-user) has to actively use the software product and provide feedback which will help guide decisions about what to include in the next incremental update. This way the software product is constantly transformed and the customer must take the initiative to shape it to achieve the tangible results they need. This process of continuous feedback and constant transformation is how Agile is meant to function and will ultimately lead to a successful project outcome or more correctly will lead to a successful software product which leads to successful business outcomes.

*This can vary with every project and its scope, but 2 months is a good measure of time to show some output