TechRepublic met with Patric Palm, CEO and co-founder of Favro, to discuss the main differences between Waterfall development and Agile development.
Palm: Absolutely. Waterfall development is basically the idea that if you need to have an idea on how long is a certain project going to take. You break it down into its molecules and then you basically put all those tasks after each other, and if you do that with high precision enough, basically when you have your last task, you're going to have your finished product. If something gets delayed here in the middle, everything shifts later.
So you're using techniques like, for example, it's called leveling, to make sure that this is always aligned to the people that you have involved and basic how many tasks you have. That is a traditional Waterfall approach.
There's a big problem with that approach and that is that it doesn't really take into account all the uncertainties that you typically have in software development. Very often you might think that you have broken this down into great molecules in the beginning, but it's just so many unknowns that you will discover a lot of stuff during the way.
Another way I also speak about this is that, let's say that you actually do the product exactly that Waterfall way that you had planned, will you have created the best product that you could? Well, probably not, because you really want to use that learning during this journey to make sure that you make the right course corrections to arrive at the ultimate result.
SEE: IT leader's guide to Agile development (Tech Pro Research)
Now, what happened basically in the 90s was that some real large software products started to simply break down. They simply imploded. There was so much uncertainty that the traditional Waterfall method wasn't working too well. A lot of people got together and thought, "Well, isn't there a better way?" Agile isn't really one method. It's really an umbrella for a lot of different methods where maybe Scrum is the most famous one and not even Scrum is ... invented this collection of really good practices that are all optimized for change and taking the unknown into account. It's an approach for how to navigate when you have a high level of uncertainty.
This is really how these Agile practices were born, [there was] a lot of uncertainty and you do that by using these much shorter iterations, and then there's a whole package of other principles that have to do with working in much smaller teams that are more autonomous. There are some engineering practices that come with this because if you're going to work in this way, you probably also want to have the right software architecture to support, a more modular way of working so you can have these short iterations, in a good way, and so forth.
On a very high level that is the main difference between Waterfall and Agile.
- Agile development: cheat sheet (TechRepublic)
- How to apply Agile practices with your non-tech team or business (TechRepublic)
- 5 tips to developing a successful DevOps culture (TechRepublic)
- Let go of certainty, start using your brain: How to make the most of agile development (ZDNet)
- Agile: why should software developers have all the fun? (ZDNet)
Dan Patterson has nothing to disclose. He does not hold investments in the technology companies he covers.
Dan is a Senior Writer for TechRepublic. He covers cybersecurity and the intersection of technology, politics and government.