Agile, yet Rigid
The Agile framework is a very well-known and proved methodology for software developers around the world. Quality and speed is the main scope of the development method and it’s clear from seeing the key values upheld by the original signatories in 2001.
But with the advantages that come with a generalized method, there comes many trade-offs that might be hard to notice, and some of these issues are the ones we’ve encountered within the development period of HappyFresh Fleet Tracker.
Large and Strict Commitments
This is something I personally experienced in the development cycle, where hundreds of lines of codes were “wasted” as the requirements themselves were changed between each development cycles or “Sprints”.
This happened during the second sprint, where our clients at HappyFresh requested us to use a particular geolocation service API. Development then started as usual and I began working on the front-end implementation using the API. However, during the meeting at the end of the sprint period, our client suddenly told us that they got the greenlight from management that they have enough budget to cover for the more expensive-yet-complete API.
The problem happened mostly because we were committed to the goal set at the beginning of the sprint, and the lack of communication in between these sprints. Compared to other methodologies like extreme programming where the time between planning and product delivery/live testing is days if not hours, Agile’s “sprint” system might prove to be less lenient towards situation like the one we’ve experienced.
Emphasis on Users/Clients
This might be a weird one to bring up, and is certainly a double-edged sword in the process of our development. Agile requires that each sprint involves all parties to discuss the development process of the sprint past and to come. This took quite a toll on us as our client is not always readily present, with commute between UI and Talavera requiring around an hour of traffic, and video calls being ineffective in addressing a lot of issues that we’ve faced, as most of their development team were not present during it.
The cycle of feedback and adaptation-on-demand is a very tasking process in our development, and with the added challenge of HappyFresh being difficult to get in touch with, a lot of our problems that we’ve faced couldn’t be solved by Agile’s sprint system. This was also part of the reason why the API issue stated above happened, as we did not have clear communication between sprints.
Had we used another methodology that emphasized communication within a shorter time-frame or product delivery based on initial requirements (which would stop user from changing requirements mid-cycle), the problem we faced wouldn’t have happened.
Agile is certainly a very well-defined methodology and generally a good way of running a software development team. It seeks a win-win condition for both developer and client, and does a great job of ensuring balance exists between them. But without careful and critical planning, problems may arise due to the limitations that the method imposes on developers.
