Successful outcomes are 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:
- Meeting all of the predefined project goals
- Each component of the software satisfies the acceptance criteria set for them
These definitions seem alright at first glance, but they are superficial. They don’t consider the intrinsic difference between a software project and a non-software project—a software project results in a product being created. However, treating the software product as complete once you have finished the project is a fallacy. Once we have created a software product, we can transform it, so we should never treat it 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 project.
The definition that I like to go with is: The software adds value to the business in a tangible manner.
The adding value here refers to various scenarios that we can quantify in some form, so they are tangible – an increase in subscribers, savings in time, enhanced productivity, improved efficiency, and higher profits. At the end of the day, the software helps the business grow. With this definition, the genuinely successful outcome occurs after deploying the software, actively using it and seeing tangible results.
The reality of how a software project plays out is that one truly understands what the software must do to achieve those tangible results only after they start using it actively post-deployment. This kick-starts the process of constant requests for changes and deviating from the initial Software Requirements Specification (SRS). While this is not a bad thing, it can lead to a feeling of having wasted a lot of time on something that was not very useful, leading to a general notion of a failed outcome for the project. But the project is not the failure; it is the approach of the people involved.
In the Agile methodology of software development that we follow at my firm, we request this of the customer (a product owner, client or end-user): ‘Tell me what you want to do with the software, not what you want the software to do.’
This helps establish the customer’s 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 to:
- Provide an initial working version of the software in the hands of the customer ASAP, something which you can achieve in 1 to 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, you have room to transform the software product constantly, and the customer must take the initiative to shape it to achieve the tangible results they need. This continuous feedback and constant transformation process is how Agile should function and will ultimately lead to a successful project outcome or a successful software product, leading 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
