August 17, 2015

Agile for Ever-Changing Requirements

Three buttons in the main menu today and only two tomorrow. Mobile applications such as games require lots of tweaks and updates to be able to capture the right feeling and experience for the users. This means that even with the most detailed planning phase, as development progresses and the stakeholders are able to test and assess the app, they will either request for features to be added, removed or modified. The Agile software development paradigm exists for this particular reason.

Basically, Agile is able to quickly adapt to changes by promoting adaptive planning and evolutionary development. It relies heavily on collaboration between self-organizing. cross-functional teams. In my experience, the scrum methodology has proved to be a lot of help in getting things done.

My favorite is the daily scrum meeting (a scrum meeting can last around fifteen to twenty minutes). Usually very brief, it aims to call out the progress updates, action items as well as the issues of the team members involved in the project. It may seem to be a hassle for some to halt their momentum and report to scrum meetings but in the long run, it is beneficial since the project manager can easily keep track of the project’s advancement as well as address any issues that arise as soon as possible. It is also a good way to know if the project is still on the right track and is fulfilling the existing product requirements. Also, by constantly communicating with each other, changes and additions etc. are immediately raised so adjustments to the product and its timeline can be made as soon as possible.

The next thing is the sprints. Sprints are kind of like checkpoints. You get a week or two’s worth of tasks from the backlog and proceed with the development. At the end of every sprint, features are checked by the stakeholders. This way, any changes or updates that they may request may be accommodated in the next sprints. In other paradigms, in which development is continuous and the app is checked by the stakeholders only after all the development and testing is done, a lot of time is wasted on behaviors/features (especially ones that are related to others) that would eventually be removed or modified.

In terms of collaboration, it was mentioned that the Agile methodology relies on     self-organizing teams. This is especially efficient since no micromanagement is required. We always assume that all teams in the project (front-end/back-end development, creatives, quality assurance etc.) have their own way of managing themselves. The main thing is that they are able to meet the requirements of the project.  As the project manager, I only need to facilitate the scheduling, communication and integration between the different teams and make sure that all of them are aligned towards the same goal.

We can’t always hope for a project with very little changes. What we can do is be flexible enough to handle the adjustments without sacrificing quality or efficiency and in several of my projects, the Agile methodology has proved itself to be a good way to do just that.



Add comment

Log in or register to post comments