If you are interested how Agile compares to a more traditional methodology such as the Waterfall, you are in the right place. In this article I will break down the key differences between . these very different software development approaches..
What is the difference between Waterfall and Agile? The main differences is an iterative approach as opposed to a rather rigid sequential approach. Agile has agreed work packages, called sprints, that can be changed or improved as the project progresses, as appose to waterfall which has sequential phases from design to development through to testing.
To get the full detail on this continue to read on. I will break down 11 differences between Agile and the waterfall method.
So as mentioned briefly before Waterfall has phases, instead of sprints. In Agile you have bits of functionality that are grouped together in what is formerly known as sprints.
For example, if you're working on a website graphical user interface, e.g. your first sprint might be the general layout of the actual graphical user interface (GUI).
And then at the end of the sprint, after testing the developed software, you would present this to the team so that they can get an idea of if they like what they see.
After they agree with the functionality, the next sprint maybe to improve on that, add more features or functionality and do this in a continual process until you get to the final end product.
As opposed to the Waterfall model where you have a requirements phase, a design phase, and each phase is locked down, signed off, and then you move to the next phase. Once the requirements are done, there's no going back.
So as I previously mentioned, in th Waterfall method, each phase is effectively locked in and agreed, without any flexibilty.
So what this means is, once you, for example, finish the requirements phase in Waterfall, you then have a document which is signed off by all parties and once that's done, that is cast in stone. You will then stick with these requirements to the very end of the project.
Whereas, with Agile, you will effectively be evolving the requirements ongoing from the beginning to the end of the project. So at the beginning the whole requirements could actually change significantly by the end, which gives you more flexibility.
So a bit of an overlap with the last one, but the main focus here is once the requirements are done, there is no changes. They're locked down and they're cast in stone.
Effectively it's quite expensive in Waterfall to make a requirements change because you'd have to go back to square one, make changes to the requirements doc, which is pretty much like the underpinning overarching document that dictates the entire project phase and then roll out the design implementation and testing all over again.
Whereas in Agile is quite dynamic and you can effectively make changes on the fly and then work them into the next sprint of work and gently evolve. Both of these, by the way, have their pros and cons, but there is a very big difference between these models.
What this basically means is in the Waterfall model, you have a very specific testing phase. Once you exit the testing phase and it's signed off, you are then done with testing for the entire project.
With Agile, on the other hand, you break everything up into sprints and effectively you're testing throughout the whole project and you can continually change requirements. Development code will change and you'll continually keep testing within each sprint.
For example, for those that don't know what a sprint is, it is a short phase that could be anything as quick as two weeks, finish a piece of functionality, test it and then restart the next sprint and you're continually testing, developing, coming up with requirements and so on and so on.
So with the Waterfall method, typically the customer really doesn't get involved until the very end of the project when everything is already delivered, done, tested and everything is signed off.
The customer really just has a hand in agreeing the requirements. But as far as seeing the end product, they don't get involved until the end. Whereas in Agile, on the other hand, the customer is involved from the very beginning because they get to see working prototypes in each sprint and get an opportunity to give feedback that can dictate how the project moves forward.
So with the Waterfall method, each phase has its own team of people that work on it and sign it off. So for example, when you do development, you have a development phase, whether that be for two weeks, two months or even two years, whatever the duration.
You have a specific team that will focus on that particular activity and once it's signed off it will then move on to the next team. So it's pretty much focused in departments of work.
Whereas with Agile you will have very small sprints. Development is done very quickly, then pass the code to the test team who then test it and then give their feedback immediately back to the development and project team. Then changes are made in development to update/improve and so on and so forth.
So in effect, you've got a very tight knit collaborative environment as opposed to a very much siloed off sequential focused model.
Suited for defined requirements, for example, a banking application versus evolving requirements such as a startup. What does this actually mean?
In essence, Agile is more geared up for a very dynamic environment where requirements may not be actually defined from the beginning. Whereas if you may have, for example a legacy banking application and you've got requirements that had been locked down from the beginning and you know exactly what you're delivering.
Then a more traditional Waterfall model or maybe even a V-Model will do for this manner may be the best thing to do.
Waterfall method is pretty much based on delivering and following a very strict project methodology. Agile, on the other hand, is more based on coming up with the very best product.
Therefore you're looking for feedback from the customer to see if you're on the right track to deliver what they want. It's very much focused on the product itself rather than following a very rigid project methodology.
The Waterfall model is very good from a project perspective because you've got very clear milestones and you know exactly where you are and it's easy to estimate and allocate jobs/tasks.
However in Agile it's very much dynamic and can be a bit harder to project manage, but at the end you're hoping to get something which the customer is more happy with at the end.
So with the Waterfall model you have very limited communication until you very much get to the end of the project. And when I say limited transparency, it effectively means once the requirements are agreed, you then go into project delivery mode.
Bare in mind, this could take two to six months and then by the end of the project, without having much transparency, you get delivered the end product and it's fingers crossed that the customer's happy with what they see.
For anyone that's spent any length of time in the software development or the testing industry, you know that it's very difficult to actually deliver exactly what someone expects without them seeing it up front, and this is where Agile has become quite popular in recent years.
It's been the answer to some of these challenges. Obviously Agile is not perfect in every shape or form, but it does address this aspect very well.
Quite controversial, but hear me out first. The Waterfall methodology is quite good from a project management perspective because you've got very clear requirements.
These requirements can be mapped to test use cases, they can give you visibility of how long the project is likely to take, they can give you visibility of who's going to be responsible for producing each deliverable and it's very easy from a project management perspective to follow.
As opposed to Agile, which some people have used the term "organized chaos", which is quite harsh because obviously it does have some great values.
The problem is it's very hard to project manage in some aspects because it's very unclear exactly how it's going to evolve at the end product and exactly how many people you need to resource because you don't know if the project requirements are going to change significantly during the process. So it's almost like a moving target.
What I mean by this is with the Waterfall model, if you decide to make some fundamental requirement changes halfway through the development phase, for example, three months down the line of a six month project, it's quite an expensive change.
Bear in mind that a whole project team could have maybe 20 highly paid professionals who are costing the project tens of thousands, maybe even hundreds of thousands of pounds.
Therefore for you to make a requirements change could mean going back to the beginning, making changes, getting it signed off, get all these people in a room to agree to these things, rolling out development testing again, effectively turns out to a very costly mistake to get the requirements wrong.
However in Agile, if you find that there's something not quite right in the requirements, you can simply make a very quick change rollout a new sprint and then you're back in business.
What is the difference between Scrum and Agile? I think it's more of a misunderstanding of Scrum. Scrum is actually a framework of Agile, so effectively they're one of the same thing,
There are other types of frameworks, e.g. Kanban which you may have heard of before, but Scrum is something which is really Agile.
Is Agile more expensive than Waterfall? Essentially this can be quite subjective depending on which project you're working on.
If you're talking about requirements changes, then definitely Waterfall can be very expensive in this process. Agile, again, it could be argued to be more expensive because you don't actually know exactly how much resources you're going to need to throw at it from looking at it at the beginning of the project.
As discussed earlier, this is because you don't have clear visibility of how it's going to transpire. In my opinion, the Waterfall is quite expensive because of the lack of flexibility.
You cannot be as dynamic and make quick requirements changes. So in my opinion, I'd say Waterfall is quite expensive, but there are cases to argue it on both sides.
What does Scrum stand for now? Scrum is not really an acronym. This is also probably a misunderstanding or misconception. Many people believe that Scrum is broken down into an acronym, but it isn't actually.
Scrum is just a word used to talk about this framework of Agile and doesn't necessarily mean an acronym. So essentially it doesn't really stand for any particular word or acronym at all.
So what is Scrum SAFe? Stands for "Scalable Agile Framework". Scrum SAFe is an implementation of Scrum. It's A scaling framework to take Agile to an enterprise level.
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.
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.
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.
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.
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.
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.
In my years of testing one of the most important things I have identified is Acceptance criteria. Unfortunately, I have seen too many projects focus on what they think is right, rather than what was agreed and defined in the Acceptance criteria.
What is Acceptance Criteria? Acceptance criteria is the agreed conditions that a software program should meet to be accepted by a customer or stakeholder. It defines what is acceptable by the program to insure quality.
Typically, this acceptance criteria is broken down into 3 areas, functional, non-functional and performance. If you have been around in testing for a while, or been looking for testing jobs, its likely you have heard of these terms before.
As the name suggests this breaks down the functional areas, such as “A User Login”. This is a specific function of the system that will have acceptance criteria, such as, once a valid password and user name is provided, the user will gain access.
A good example of non-functional is the design and layout of a corporate website. This is different to a functional module I this sense. So, if we extend the example of the corporate website, you may want your site to follow your agreed brand colours. Therefore, a non-functional criteria item could be verifying this has been met.
Performance is different to functional. It focusses on certain agreed performance metrics for the software. For example,
“The system must load the contacts page within 10 milliseconds”.
“The system must be able to support the load of 100 simultaneous users”.
These are just quick examples to make sure you understand what I a mean, they are not the perfect example of a well drafted user story.
Acceptance criteria, done correctly, should not explicitly state how to technically do the solution. It should clearly state the intention. For example, it shouldn’t say to authorise the invoice, the supervisor must click the “A” key. It should be saying; a supervisor can authorise an invoice.
In other words, it should not be biased to any form of implementation. The design and execution of the test is different, this is more for an acceptance test.
Acceptance Tests, on the other hand are tests to prove that the acceptance test criteria has been met. In agile, they are typically derived from User stories. These tests are usually conducted by the actual user. Which is different to unit tests, for example. Because Unit tests are usually ran by developers.
These tests are also referred to as “black box tests”. Reason being, the user looks at the tests at a high-level functional level, without any need to understand the coding conditions and interaction between modules.
White box tests, such as unit testing on the other hand, focus on how each code module interacts together and focuses on the inputs and outputs of the modules.
Acceptance Criteria is closely tied to a User Story. The user story will prove if the Acceptance criteria has been met. This is why it is important that the criteria is clear with an obvious pass or fail. In other words, it should not be subjective or ambiguous.
Think of the Acceptance criteria as the foundation of your house. If they are not sturdy, the whole development project is doomed!
In Agile The user stories are created to prove that the criteria has been met. Following on from this, Acceptance tests are created to prove that the user stories have been implemented. This can be manual or automated tests, that choice is down to the team or business.
Once the criteria is defined it is possible to group the user stories in to modular tasks. Once this is done then this will help to plan and estimate testing activities.
This task is usually done by the customer or stakeholder. However, the process involves close collaboration of the project team to review, agree and refine the requirements.
This review and collaboration is important because, whilst the customer knows what they like, they may find it hard to define this within a framework that can be used to code or test. For example,
Saying things like: “The system should load fast”
This statement is not a useful or useable Acceptance criteria. Because it doesn’t define what “fast” is. Believe it or not, fast can mean something completely different for each individual in a project team. If we use the house analogy again, if you asked your builder to create a “Big House”, you could be thinking a 6 bedroom detached, he could thing a 3 bed semi, with large double rooms, are you with me?
So, this is why they are reviewed and defined.
What is an acceptance criteria format? One of the most common formats for acceptance criteria is the “Given when then” format. It makes it easier to define it. Like most things it’s easier to explain with an example:
Given [a certain pre-condition], When I do some type of Action, Then I expect this to happen
This is quite an easy format to follow for any given scenario you may have.
How can Acceptance Criteria Benefit the Project? It is very easy for a project to go over time and over budget. But with the use of a well-defined criteria it can help the development stay on track and focus on what needs to be delivered.
What is an example of an Acceptance story? If we use a banking application as an example. You may have the following acceptance criteria:
“The users bank statement cannot be displayed if an unknown bank user ID is provided”
This criterion may be accompanied by this User Story:
As a Bank User
I Can See My Bank Statement
So that I know how much funds I have
Dos and Don’ts for creating Acceptance Criteria? : To make life easier here are some do’s and don’ts to create your criterion:
Hopefully this has helped you to understand What acceptance criteria is and more importantly how you can use it for your agile project in the near future.