Before you can even embark on a software project, you must decide with methodology to use. Those who prefer traditional methods will likely choose the waterfall approach, and those who have become tired of waterfall will chose the agile approach. Susanne Madsen recognizes in an article for PM Hut that many projects end up following a methodology that would be placed somewhere in the middle. These methodologies seem more flexible to the waterfall advocates and much less flexible and collaborative to the agile advocates. However, just because many projects end up in between methods does not mean that your project team should not attempt to choose one or the other. Madsen offers eight questions to ask yourself when trying to decide whether agile or waterfall is right for you:
- How clear are the project’s objectives and requirements?
- How clear and well-defined is the solution?
- How easy or difficult is it to access the end users?
- What is the size of the project?
- How dispersed is the project team?
- What is the team’s and stakeholder’s experience with these methodologies?
- What are the project’s success criteria?
- How much value would incremental feature driven development add?
The first things you need to find out is if you can clearly answer what you want this project to do. Then you must assess how well defined your solution is:
On some projects, the clients know exactly what they are looking to achieve and what the success criteria of the project are. On other projects, it can be difficult to pinpoint what the project needs to achieve or what the requirements are. When the requirements are difficult to define, or likely to change significantly, you need an approach which is relatively experimental and flexible; an approach which allows you to speedily demonstrate and prototype ideas to the customer and incorporate changing requirements.
You may find yourself in a situation where the desired outcome of the project is clear, but where the solution for achieving that outcome is not. When the team is faced with difficult and risky choices around technology, design and implementation, your software development methodology needs to be flexible enough to cater for this and iterate through various stages of prototyping, development, and roll-out.
You must next figure out the level of difficult you will most likely face when accessing the end users. If you are facing a great amount of difficulty, your methodology should be more rigid. You must also consider the size of your project. If your team is small, Madsen suggests a more flexible and agile approach would be more appropriate. This is also true if your team is working together in the same place. However, if your team is more spread out, they will be less likely to be able to adapt to quick changes, and therefore a more traditional approach would work best.
Even if your project ends up being somewhere between agile and traditional, it certainly does not hurt to ask yourself Madsen’s eight questions before beginning. Even if you do not end up sticking to one method from beginning to end, you will likely be able to make some choices that will make working on the project easier for everyone involved. Every project team is different, so remember to gauge your own situation instead of relying on what others have done.