If you are researching Agile, or interested in giving it a go for your next project you need to know all of the pros and cons. If this sounds like you, you are in the right place.
What are the Agile model's advantages and disadvantages? The advantage of agile is speed, flexibility and transparency to the end user. The disadvantages are its difficulty to project manage and scale for large projects.
Understanding the pros and cons is just one part of the challenge, you need to know how I have come to these conclusions to fully appreciate this. Continue reading to get the full in-depth low-down.
Agile is a really good, fast and efficient methodology to roll out a software project. If you are testing, which primarily you will be if you're on this page, or a developer, it's a quick way to get stuff out as soon as possible.
Disadvantages, if you're more of a traditionalist or you've been in the game for as long as I have, you may find a lack of documentation can be a real headache and hard to get your head around. So stick with me. In this article, we're going to go more in depth into explaining these advantages and disadvantages and also give you some other in depth information about Agile.
Speed of Delivery
In a nutshell, Agile is an incremental software development methodology that allows you to get quick feedback on your code modules and get stuff out quick to market.
The way it's typically implemented is, you break down your delivery into small modular sprints and you test and develop, get feedback and reiterate around, around again, allowing you to get code completed quicker.
An added benefit is, rather than having to spend months on planning, designing and building documentation before you start coding, you can dive right in.
So one of the advantages, as you may have guessed is the speed of delivery.
Agile is great for getting the ground running, getting something out and getting early feedback.
Without Agile, you could you spend months of planning and designing, only to find out that your efforts are no longer needed by your stakeholder or they just generally do not like what you've delivered.
And believe me, I've been testing for a long time now and I've seen this happen before. Early feedback falls in line with speed of delivery, you can roll out a few iterations.
Let's give you an example. You could be building a graphical user interface for a web application, rather than spending months on design and documentation then having a UAT testing phase at the end to introduce your customer to the actual product.
You could instead use agile, roll out a very basic wire frame of the graphical user interface with a one or two weeks sprint, roll it out for some testing, get some feedback from the customers.
And then with the feedback that you get from them, whether it's positive or negative, you can actually update your designs or code to be in line with what their expectation is and reiterate that again in the next sprint.
Flexibility with Late changes in requirements
This is another great thing. Agile is not as rigid as the V model or the Waterfall model. So you do not have to go back to design and documentation if there is a change in requirements and avoid loads of meetings to agree the changes.
You can simply "tweak the changes", add it to the next sprint, redevelop the code, update the code, or whatever it may be, retest, and then roll it out.
Close collaboration with project team
One of the benefits of this is you can collaborate closely with the project team and it allows "buy in" from all parties in a project team.
For example, the project manager can have a good view of the next sprint. The stakeholder can get some feedback on the project early, for example, at the end of a two week sprint, before it's actually too late to make changes.
It's also a good opportunity for testers to get an early hand on the code. In summary developers, stakeholders and all project members tend to collaborate tightly together.
One of the great things in Agile, which is known as a scrum, is a great opportunity for all stakeholders to get together on a daily basis to see how the project is unfolding.
Hard to estimate the length of the project
Now one of the disadvantages is it's hard to estimate the length of the project. Admittedly, this depends on how you implement Agile, because every company has their own flavor of how they actually implement this.
Regardless of what you may have read in a book, every company does it slightly different and being in the game for just over 18 years at the time of writing this, I've seen many different flavors or implementations of Agile.
So in summary, sometimes it's very hard to estimate the length of the project because there is a tendency to continually add new sprints and modules and never really have a known end date.
Lack of documentation.
If you're a traditionalist or someone that's worked in the game for quite a long time and you've used models such as the V model, you can find the lack of documentation in Agile quite hard to actually deal with.
It's something that is seen as a negative, but it's a matter of opinion actually because some people believe this is a bonus because they don't have to get bogged down with months of planning and filling out documents.
Their argument may be, they'd rather use that time on getting feedback from their clients. So an advantage for some, but in my opinion a disadvantage is the lack of documentation.
If you have been testing for a little while, you've probably heard of scope creep before. Scope creep in general is when you have some agreed requirements, but then you find over time you start to go outside of those requirements and you start to deliver something slightly different.
Sometimes this can actually be a gift, but it can also be a curse because you can end up spending more money on the project than was expected and delivering something which is slightly different to what you've agreed for.
This can be quite a costly mistake. In Agile it's very easy to do this because it's so flexible, you don't have the entire scope nailed down from the beginning. So it's very easy to go off on a massive tangent.
When should you use the Agile model? That's a very good question. In my opinion, the Agile model is really good for projects where you want fast delivery, something which needs feedback really quickly.
It's ideal if you've got a web application that you can get feedback from your client, update and go forward. If it's a more complex financial application, it may be debatable if this is the best model for you.
I'm not saying it's not being used in applications like this before, 'cause I'm sure it has, but the big thing is if you're using Agile and you've got a very large team, which has got mixed opinions on agile is quite hard to get the buy in from every member.
For it to work really well, you need the "buy in" from all parties. You need to have all stakeholders in agreement and it's good to use when you start from a fresh, maybe as a startup where everyone's all on the same page, as an existing legacy system.
For example, a financial application that may have been around for 10, 20 plus years using the V model for example for many years and then overnight to switch to Agile and using existing processes, it can be very hard to actually implement.
So what are the advantages of the Agile methodology over the Waterfall model? The Waterfall model is one of the more traditional models where it's heavily reliant on documentation and following a very sequential road to delivery.
The Agile is quite efficient and quite agile and hence the reason why it's called Agile, because it allows you to basically make quick changes and it's very good at rolling out fast delivery and getting fast feedback.