The goal of any software should be to provide the best value possible while maximizing profits. The software development process is critical in ensuring that the Return on Investment is optimized.
Agile principles for software development can be a means to foster perpetual value (i.e., strong ROI). There are several important benefits and pitfalls of an agile (or iterative/incremental) methodology that are worth mentioning and which potential customers should be aware of. But Agile is also misunderstood. It is more of a way of working based on a set of values and principles than processes and standards. Organizations need to decide if going the Agile way provides value to them because many times, organization culture needs to transform for Agile to be successful.
Here is our account of how Agile can provide that ROI your organization needs and the factors you should keep in mind before deciding to go the Agile way.
The problem with risk is that sometimes you see it coming…and sometimes you don’t. In many cases, perceived risks to a project may prove not to be risks at all while unanticipated risks may surface out of the blue. Because many risks are only addressed and discovered during integration, an iterative approach provides a far better opportunity to mitigate them early on because the iterative approach is a near-continuous integration.
Additionally, Agile practices introduce a level of transparency during the development process that helps identify and mitigate risks in a timely fashion.
What used to be uncertain, long, and difficult to plan accurately (taking up to 40% of the total effort at the end of a project) is divided into 6-9 smaller integrations that start with far fewer elements. Mitigating risk is important in increasing your ROI and an important advantage of using agile principles for software development.
Changes in requirements and scope have always been primary sources of trouble for a project, leading to late delivery, missed schedules, and unsatisfied customers. An iterative approach allows for a change in requirements.
We expect users to learn from their experience in using a module in production. This, in turn, results in better requirements or optimization of requirements for future iterations. Agile practices support such changes. As they learn more about the environment, technology, and their own business, and see intermediate demonstrations of the product as it is being developed, this additional knowledge contributes to new ideas/requirements and thereby fosters a more comprehensive business solution in the end. Change can also come about through environmental changes or changes in strategy. While agile practices support such changes, we must caution against rushing to make such changes without considering impacts on budgets and other competing priorities. After all, every new requirement or changing requirement results in time being added to an initiative. Not providing users with an opportunity to learn the system and then optimize and in certain cases even remove certain unnecessary requirements is not only unrealistic but, detrimental to true success.
Iterations also allow for technological change. If technology changes or new technology appears, they can take advantage of it. This is particularly relevant for platform changes and lower-level infrastructure changes.
An iterative approach results in a more robust architecture. Flaws are detected and corrected earlier in the project lifecycle. Performance bottlenecks discovered early can be reduced, as opposed to being discovered on the eve of delivery. Iterative testing, as opposed to executing acceptance testing toward the end of the project (as in the case of the waterfall model), could result in a more thoroughly tested product. Agile is also increasingly leveraging automation in testing that brings more efficiency and predictability resulting in higher quality software.
An iterative approach provides opportunities for the entire project team to enhance their knowledge and skills throughout the project lifecycle, contributing to the ultimate success of the project. It provides more opportunities for lessons learned. Testing starts early, technical writing starts early, and developers start coding sooner. The result is a better system supported by better training and help materials, making for happier and more accepting end users. Lastly, the need for additional training or resources can be detected in early iteration assessment reviews. After all, why put off till tomorrow what is better accomplished today?
Though agile has many advantages, if not planned and executed well, it has potential pitfalls as well. Let’s look at a few of these.
Changing requirements and great flexibility also come with the risk of implementation delays and the project timelines not being met. Functional requirements that customers want in their final product can change and provide more flexibility, but it could be a double-edged sword. Many times, requirements are not well defined. Reworking on poor requirements can increase development costs. We have years of experience scouring through requirements and while we appreciate the flexibility agile gives, we would like to mention that writing requirements that are well defined are something customers should provide importance to. Here is a simple workbook to check if a requirement is a winner or a stinker.
Since agile requires continuous collaboration and buy-in, commitment from the business owners and teams might become a problem. It can also pose a challenge in large projects where teams (business and developers) are not present in one-location.
Customers need to answer to their stakeholders about a project and may want to know what they are getting for their money as early as possible. It can be far harder to estimate timescales and costs as there is less 'definition' to base estimates on. Vendor relationships with customers need to transform with agile as some of the scope is open-ended.
In lieu of the current technological paradigm, the benefits of agile development to increase ROI are both numerous and critically important. To foster long-term value and reduce the threats of project success, it pays to be flexible. On the other hand, agile is a way of life, it requires specific conditions that relate to the work environment, buy-in, and commitment from all stakeholders. Our advice is to first solidify your objectives, timelines, and commitment before taking on agile or any other methodology.
Have you undertaken an Agile project in your organization? How has agile development added value to your IT system?
If you would like to read more about Agile, here is a blog from our expert Subodh Murthi.
Download our free insider's guide to learn more about understanding and evaluating functional requirements for your IT system RFP.