{"id":1794,"date":"2015-03-06T06:00:00","date_gmt":"2015-03-06T14:00:00","guid":{"rendered":"http:\/\/thinkapps.com\/blog\/?p=1794"},"modified":"2015-03-05T23:57:25","modified_gmt":"2015-03-06T07:57:25","slug":"waterfall-vs-agile-software-development","status":"publish","type":"post","link":"https:\/\/thinkapps.com\/blog\/development\/waterfall-vs-agile-software-development\/","title":{"rendered":"Waterfall vs. Agile Software Development"},"content":{"rendered":"

Planning to hire\u00a0an external developer but\u00a0not sure\u00a0whether to pick a team that will follow a waterfall or agile development approach? Read on for expert advice.<\/em><\/p>\n

Innovative visionaries, product evangelists, extreme problem-solvers, tireless fundraisers \u2026 today\u2019s startup\u00a0founders must\u00a0wear many hats.<\/p>\n

But it turns out there is at least one more they often need to fit into their wardrobe: the hat of wise development\u00a0team chooser.\u00a0And it’s not an easy one to wear.\u00a0<\/strong><\/strong><\/p>\n

For a technology startup, whether it builds products or software as a service (SaaS) solutions, there are at least two significant decisions to make. The first is which developers to hire, and the second is which development\u00a0method to utilize for the project.<\/p>\n

As I will explain below, these are\u00a0not only technical decisions, but decisions that are vital to your company\u2019s very existence.<\/p>\n

Where to Start?<\/h2>\n

As is probably obvious,\u00a0not all startup founders are programmers, not all of them know how to code. But if their dream (or their plan, to be more precise) is to build a\u00a0company around a software product, they need to understand\u00a0the various ways in which software can be built and decide which approach is best for their business.<\/p>\n

The choice is not trivial and depends on how you answer the following questions:<\/p>\n

    \n
  1. To what extent do you actually know how\u00a0your product is going to look and behave?<\/li>\n
  2. How much involvement do you want to have in the software development\u00a0process?<\/li>\n
  3. How much do you trust your developer team?<\/li>\n<\/ol>\n

    With these questions in mind, let\u2019s take a detailed look at two of the most common types of software development: Waterfall (traditional) and Agile (iterative).<\/p>\n

    Waterfall (Traditional)<\/h2>\n

    Waterfall is a linear approach to software development.<\/p>\n

    That\u00a0means that project stages are executed sequentially, and no stage can begin before the previous one is finished. You receive your completed project, fully developed and tested, at the very end of the process.<\/p>\n

    \"software-development3\"<\/a>\u00a0<\/strong><\/strong><\/p>\n

    Image credit<\/a><\/i><\/p>\n

    Specification<\/h3>\n

    The first stage of a waterfall process is gathering requirements for the whole system. That\u00a0means that before design starts, you\u2019ll need to determine\u00a0how\u00a0the application will look and behave.<\/p>\n

    Beware! For waterfall, it\u2019s not enough to say that you want to build a clone of another web or mobile service. All features should be listed in the agreement you sign with your software developer. For some startup founders, this can be an extremely difficult task.<\/p>\n

    More than once or twice, we talked to clients who were convinced they explained everything in a short brief. But your project is much more valuable than just a brief, and your software team needs to understand it as well\u00a0as you do. So be prepared for hundreds of questions and diving\u00a0deep into the details, much deeper than you probably ever expected.<\/p>\n

    On the other hand, the advantage is that when development finishes, you\u2019ll be able to easily determine whether the product you received is the one you wanted in the first place.<\/p>\n

    Involvement<\/h3>\n

    You already spent a fair amount of time at the outset gathering project requirements. Are you sure you have enough of it to be constantly involved in building the product? The good news is that, if your software company uses waterfall methodology, you won\u2019t have to.<\/p>\n

    Because of the thorough collection and analysis of requirements at the beginning, \u00a0it should be clear as day what should be developed and when. Apart from approvals, reviews, and status meetings, your presence will not be needed\u00a0after the initial requirements stage.<\/p>\n

    Trust<\/h3>\n

    For a waterfall project, the most natural way to structure payment is fixed price.<\/p>\n

    You know exactly what you want, developers know exactly what to do, and the deadline is set, so you can easily agree on the cost. Therefore\u00a0staying on a\u00a0strict budget shouldn\u2019t be a problem at this point.<\/p>\n

    But remember, once\u00a0development starts, you won\u2019t be able to add a single feature without adjusting the budget. And if\u00a0it turns out that\u00a0your requirement analysis wasn\u2019t thorough enough, you will end up paying a fixed price for a project that doesn\u2019t match your needs. That\u2019s the risk.\u00a0<\/strong><\/strong><\/p>\n

    All in all, traditional ways of building software are a good match if you want to build an MVP and you\u2019re 100% sure of all the requirements it has to meet. It can be tricky for mobile apps when operating systems change frequently and often entail rebuilding the app to some degree to match\u00a0the newest system release. For short projects (up to two months) with\u00a0clear expectations, though, waterfall seems to be a good fit.<\/p>\n

    It is\u00a0interesting to note that all of our clients came to us with fixed-price projects initially, but as their software grew, the approach became more flexible. Now 90% of our projects are developed through an\u00a0agile process.<\/p>\n

    Agile (Iterative)<\/h2>\n

    Agile development, as opposed\u00a0to waterfall, focuses on building software iteratively, according to principles of the\u00a0Agile Manifesto<\/a>.<\/p>\n

    The project is divided into small modules (the smaller, the better) and delivered in weekly or monthly sprints. During each sprint, a certain functional set of features is developed, tested, and delivered to you for evaluation. This approach emphasizes rapid delivery.<\/p>\n

    \"Agile<\/a>\u00a0<\/strong><\/strong><\/p>\n

    Image credit<\/a><\/i><\/p>\n

    Specification<\/h3>\n

    With\u00a0agile software development, it\u2019s not necessary to have all of the requirements collected in the beginning. What is done in the initial phase\u00a0is collecting all known requirements in a project backlog and translating them to user stories (what you need) and tasks (what developers are to do).<\/p>\n

    This process\u00a0is usually done through\u00a0a\u00a0project management tool such as Pivotal Tracker<\/a>\u00a0(paid) or Taiga.io<\/a> (open source). Keeping\u00a0in mind that you can broaden your project scope at any time, developers need to build the product in a very scalable way. In agile software development, teams usually use Scrum<\/a> or Kanban<\/a> as their agile framework.<\/p>\n

    If you look for agile derivatives, you\u2019ll also come across Lean Software Development<\/a>. It comes from Lean Manufacturing<\/a>, which was created by Toyota to eliminate waste in production cycles. Mary and Tom Poppendick<\/a> adapted the concept to fit software development. The idea is not only to be flexible to change and proactive (as in agile), but to focus on what brings value to the project and eliminate every activity that doesn\u2019t add value.<\/p>\n

    Involvement<\/h3>\n

    The agile approach requires\u00a0you to be involved in the process as much as your developers are.\u00a0Communication between you and your software team should be clear and quick because time is a resource that\u00a0one doesn\u2019t want to waste.<\/p>\n

    Your project can always be \u201cin move\u201d and you are able\u00a0to change, switch or add requirements to upcoming sprints. That\u2019s where the true flexibility of agile development comes from.<\/p>\n

    Trust<\/h3>\n

    This approach is for startup\u00a0founders\u00a0who cherish relationships and trust more than anything else.<\/p>\n

    Sounds crazy? Not at all. Being able to trust your software company doesn\u2019t mean that you say what you want and they do what they want. Your project is not left alone because of your involvement.<\/p>\n

    Besides, since you usually pay for time and materials at an hourly rate,\u00a0you can resign whenever you\u2019re not satisfied with the outcome. As a result, the overall financial risk of choosing the wrong team is smaller than in waterfall where you pay when the project is ready.<\/p>\n

    Don\u2019t go chasing waterfalls if your product and business are going to evolve with your customers. By having an agile development team, you can adjust whole modules of your application in the process of building it.<\/p>\n

    In a nutshell: you can make it better before it\u2019s even released. The approach is perfect to develop an MVP for early stage customers or for a market you\u2019re still learning about.<\/p>\n

    One Size Fits All?<\/h2>\n

    So which approach should you choose as a founder? The honest answer is that it\u00a0depends.<\/p>\n

    If your budget is limited, think about whether it\u2019s possible to have your product developed at least to the MVP level that satisfies you.\u00a0Can you afford paying all the money to the team you\u2019ve just started working with?<\/p>\n

    How much time at each stage would you be able to devote to the project? If you\u2019d rather be thoroughly prepared from the beginning, gathering specifications, getting to know your market, preparing application mockups, then waterfall might be the right approach.<\/p>\n

    If, on the other hand, you\u2019d like to cooperate with the developers on a daily basis and evaluate the software frequently, the\u00a0agile approach will probably be closer to your heart.<\/p>\n

    Of course the world of software development approaches doesn\u2019t end with just those two. Many founders\u00a0reach an\u00a0understanding with their software team somewhere in the middle. That’s\u00a0OK as long as everyone\u2019s happy.<\/p>\n

    Either way, don\u2019t rush. Choose the best fit for your personality, talk to different software teams, let them show you the way they work and the results they obtain.<\/p>\n

    But most of all,\u00a0never hesitate to talk to your developers\u2019 previous clients. After all, they’ve already worn\u00a0the hat you\u2019re about to put on.
    \n<\/p>\n

    \n
    \n