Tag Archive

Tag Archives for " agile design "

What is the Difference Between Waterfall and Agile

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.

Phases Instead of Sprints

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.

Waterfall Phases instead of Agile 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.

Rigid Phases Vs. Flexibility

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.

Requirements locked down versus dynamic changes to requirements. 

Waterfall Requirements Locked Down vs Dynamic Changes to Requirements in Agile

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.

Testing once versus incremental testing. 

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.

Customer validation at the end Vs. Customer involvement from the start 

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.

Sequential department focused versus collaborative. 

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 vs Evolving Requirements

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.

Project development focused versus product focused. 

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.

Limited Communication and transparency versus the open model.

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.

Simplicity for project management versus Organized chaos. 

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.

Expensive requirement changes Vs fluid changes. 

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.

Related Questions

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. 

What is the Agile Methodology discussed in the ISTQB certification?

The Agile methodology comprises a set of values and principles applied in the processes for developing software just like other software development methodologies such as the Waterfall model. The word “agile” refers to the capability of something to move easily and rapidly. This is a major feature of the Agile methodology.

When used, it takes a shorter timeframe to complete a project when compared to other methodologies. Iterations are used in Agile projects to deliver prearranged features. The following information will improve your understanding on what is the Agile methodology discussed in the ISTQB certification.

Key Phases Involved in Agile Methodology

  1. The Concept Phase: During this first step, you and your team analyzes and arranges projects in order of importance. Each concept will require a definition of the business opportunity and how much time it will take to deliver the project.

    Once this information is compiled, you will be able to determine the achievability of each project and know which one is worth working on.

  2. The Inception Phase: Here, you will work on the requirements with the stakeholders. You can create a flow chart that explains how the feature you’re developing should work.

    You then choose people who work on your team and develop a timeline for each activity showing when specific work needs to be completed for the length of the sprint.

  3. The Iteration Phase: The developers and designers start to work on the initial iteration of the project. Their main goal here is to create a working product at the end of the given timeframe. This is just the first iteration as the product will go through quite a number of adjustments.

  4. The Release Phase: To complete the software iteration, the system is tested for errors or malfunctions. The user and system documentation are finalized for everyone to get a clear picture on how the system works and how they can improve it. After this, the iteration is released into production.

  5. The Production Phase: In this phase, your team works at ensuring the system functions smoothly and trains the users how to work with it.

  6. The Retirement Phase: It is in this final step that you move the system from production, more so when you’re ready to replace it with another release.

So What Exactly is an Agile Sprint?

An Agile sprint refers to the specific duration of time during which certain tasks have to be finished and prepared to be reviewed. Sprints usually last for about 10 working days and comprise the following steps:

  • A planning meeting where the team gets together and discusses the mechanisms for the forthcoming work.
  • Designing and developing the product keeping the official guidelines in mind.
  • Testing the results and documenting them.
  • Presenting the product to the client.
  • Gathering feedback from the client and integrating it in the next sprint.

What Does the Agile Scrum Refer To?

The Scrum is a subdivision of the Agile methodology. It is the most commonly used set of practices for Agile development. In simpler terms, it is a framework used to manage processes involved in a project. Scrum is mostly used when developing intricate software through the use of iteration practices.

It is preferred due to the fact that it reduces time and increases your team’s productivity. In addition, Scrum makes allows you to easily adjust to changes in product requirements. It helps you to:

  • Handle change easily.
  • Improve the quality of the finished product.
  • Take control of the project timeline.
  • Give the best estimates while simultaneously using less time to create them.

Scrum is dependent on a team that is self-organizing, such that the entire team will together make decisions on who will be assigned what task. Also, everyone in the team must have the ability to develop a feature from the concept to execution phase.

There are two major roles in the Scrum model; the Scrum Master who is basically the team leader and the Product Owner/PO who is the customer/user.

So what is Agile Design?

When you think about it carefully, agile design refers to the implementation of Agile development principles to the design process. Due to the fact that every designer on your team is different, it is important for you to choose the best techniques that work for you and get accustomed to them as you move on.

Some of these principles include:

  • Involving your clients in every step of the processes: This is the best way for you to ensure that the client gets a clear understanding of what they are working towards as opposed to conventional design processes that work at a creating a perfect final end-product.
  • Compile work from your teams regularly: This will help you to detect bugs or issues that may interfere with the overall product and fix them immediately or note them down to be adjusted in the next iteration.
  • Always Carry Out Tests: Frequent testing will allow your team to identify and solve problems and this will consequently catalyze your team’s creativity.

What Are the Most Common Tools Used in Agile Design?

In order to be successful, designers and developers need to seamlessly work together.
The following are some of the most common collaboration tools and software used in Agile design:

  • Slack: A chat application that keeps your team updated every minute.
  • Justinmind: A prototyping tool for both mobile and web applications.
  • Asana: Assists your teams to plan their projects and organize daily activities through a platform the enables them to track the status of their jobs.
  • Agreedo: Helps your team to plan scrum meetings.
  • ProductPlan: Assists with creating roadmaps which help your team to visualize the strategy.

To sum it up, the Agile Methodology has proven to be the best with regards to using less time in the software development process. Did you enjoy this detailed explanation regarding the Agile Methodology? I chose to cover the areas as presented so as to explain the main components involved in this methodology and in the simplest way possible.

Feel free to leave a comment below with your feedback and if you enjoyed the article, don’t forget to share it with others who would be interested in the subject.

Skip to toolbar