When it comes to trying to apply an agile methodology to our projects, we usually ask ourselves whether it is the right decision, whether it is the right project to use this method. In this article, we shall try to offer some keys to identify whether a project is capable of taking advantage of everything this type of methodology has to offer.
Classifying Projects
At some time or another we have all asked ourselves whether the new project we are about to embark on is best done with an agile methodology or if we should continue working as usual. Perhaps the project or the customer characteristics make us wonder whether making this effort will be effective. Because one thing is clear: any change in the way we work entails a cost.
There are different ways of classifying projects. One of them is using two main characteristics: requirement volatility and technical complexity of the project. Depending on each one and depending on the level, we can decide whether our project is stable, unstable, or immersed in absolute chaos.
When customers have a pretty good idea of what they want and the technology we are going to use is well understood by the development team, we can consider the project is stable.
If we are facing a project in which user requirements are in constant change (approximately 50% of them) and also the team is going to use technologies it does not clearly master or it is even unfamiliar with, then we are in an unstable scenario, since the level of uncertainty is relatively high.
Finally, there are situations where we don’t know what is wanted and the technology to be used is new or practically unknown. This situation places us in the deepest uncertainty and the probability of success for the project is quite low.
When are Agile Methodologies indicated?
One of the main characteristics of Agile methodologies is adaptability to changes arising in projects. Therefore, where they are more at ease and able to make the most of their potential is in what we defined earlier as unstable projects. Actually, the closer they are to the boundary of chaos, the better.
Thus, requirement specifications in the form of user histories and their management in the Product Backlog make it possible to manage the requirements flexibly and quickly and allow input and output of new functionalities in a much more responsive manner. Regular deliveries of working software provide early feedback for customers and users on the implemented functionality and better decision-making for new versions. The retrospective meetings held provide a continuous improvement process that helps the team.
Does this mean it cannot be applied to stable projects? Of course it can. We just won’t be taking advantage of its full potential. However, using the values and principles of agile methodologies means our teams will be more motivated, and there will be better communication and transparency with our customers. Also, the value provided by making constant deliveries of working software to our clients is a factor to be taken into account and this is applied in each and every one of our projects, regardless of the methodology. These are the main reasons why we strive to employ these work methodologies in our projects at Decide.
Moreover, I have never seen a project where the initial specifications have not changed. With our approach we can flexibly adapt to the new business needs arising in our customers’ projects and respond more rapidly to these changes.
