Tag: agile

Waterfall and Agile are the two most comment methodologies used to build software (e.g. the programs and components that make your platform or app work). In a previous post, I went through the activities involved in software development.  These include requirements, design, build, test and implement. A methodology is the way in which those activities are completed.  It’s the process that you follow to complete the work required to build a platform or app. When you start working with developers, the topic of methodology will most likely come up, so I thought I would review these with you in this article.  

Today, software is usually developed following one of two methodologies – waterfall or agile. In both methodologies, all of the activities in the software development still need to be completed – the difference is in how they are completed. To recap, the activities in software development are outlined in the diagram below:

Waterfall is the traditional software development methodology. In waterfall, you complete one activity at a time before you go onto the next one:

Here, you start with defining what you want in the requirements phase. Once your requirements have been fully-defined, you go onto the design phase. After your solution has been designed, you go to the build phase. When the build is completed, you test. Finally, once the solution has been tested, it’s implemented.

Since you must finish one activity before going onto the next one, waterfall requires that you know exactly what you want to build up-front. This means that the requirements for your platform or app have to be quite detailed. The benefit of doing this is that when you know what you want to build, you can get a fairly accurate estimate of how much it will cost.

The challenge with waterfall is if you come up with changes or additional requirements during the project. In extreme cases, you may have to go back to the design phase and re-think the solution. This often results in the project costing more and taking longer to complete. However, in most cases, if you’ve thought through your requirements, you can get a cost and time estimate for making the change that won’t have too much impact on your project. Alternatively, it becomes something you add shortly after launch.

Agile is a modern methodology that promotes flexibility. There are actually a few different methodologies that fall under the agile bannerd, but the most popular is called “scrum”. In agile, you still need to go through the processes of defining what you want, designing a solution, building it, testing it and implementing it. However, some of these activities are now done in parallel:

You start with high-level requirements of what you want to build and this is broken down into parts that are completed over a series of “sprints”. A sprint is generally defined by a fixed period of time, so you determine the contents of a sprint based on what can be completed in that time.

During a sprint, it’s a collaborative process to flush out the details of what you’re building. You and the development team work together (at the same time) to design, build and test each part. Implementation can occur at the end of each sprint or at the end of the project. An important distinction to make here is that an implementation, doesn’t mean that the functionality is made publicly available. It’s basically saying that the software is in a state that it’s finished. You may complete multiple sprints before you’re ready to actually launch the functionality to world.  

The important part of agile is the element of collaboration. The idea is that everyone is working on a part together, so as you talk about what you want, the designers and developers are figuring out how it will work, coding it, and then getting you to test it out. Given the focus of flexibility, there may be multiple iterations to get it right. It requires a lot of commitment from you to make decisions quickly so that the team can keep going. Also, if you run out of time in a sprint, any things that aren’t finished need to be moved to the next sprint.

The tricky thing with agile is that the quotes that you get will be based on high-level requirements. This means that as your project evolves, you may find more and more things that need to be included or the building of your platform or app may be more complicated than originally estimated. Your project will end up taking longer and cost more to complete. Contractually, it’s also harder to hold your developers accountable to what is delivered, because you don’t have detailed requirements to include in the contract.  

If you’re just starting out in software development, the concepts of “requirements”, “design”, “build”, “test” and “implement” are all still new to you. You’re probably not sure what you have to do and you’ve got limited funds, so you want to know that your product will get built for the amount that you’ve allocated. If you have to spend time ironing out what you want to build with your developers, you’ll pay for that privilege. So, in this case, I would go suggest following a waterfall methodology.  

This is probably going to be pretty controversial with some of the developers and agencies that you come across. However, I believe that agile works best with a trusted team (like a co-founder or full-time employee scenario), where you’re not counting the hours to get something done. Everyone on the team (including you) needs to know what to do to make each sprint count. You don’t want to run out of money before you finish building your product! You’re also dealing with a very small team – probably 3 or 4 at the most. Agile has more benefit with larger teams where people are working on different, but related things, at the same time. If you’re dead set on agile, I suggest switching after your initial launch. You and your developers will be more comfortable working together and it’ll be a lot easier to work in an agile way.

 I do have a caveat on this. I also advocate starting with the smallest possible project that you can. It’s much easier to start small and build on something that already exists. Compare that to starting with a massive project, which will carry with it a lot more risk. Remember that you can always implement without launching, so the waterfall approach can become pseudo-agile with lots of small projects. This will allow you obtain some of the benefits of agile, while allowing you to gain experience on how software development works and to get a more accurate estimate of the costs.      

So there you have it – an introduction to waterfall and agile.  A basic understanding of these methodologies will give you some context into how developers and agencies build platforms and apps.  If you have any questions about this, please pop them in the comments below.