The choice of the right software development methodology is a fundamental decision and often determines the success of a project. The most frequently mentioned methodologies are the waterfall and agile approaches with all their variations such as Kanban, SCRUM, etc.
With over a decade of experience in software development, Vasterra has identified agile as the most productive form of project delivery. We combine several agile approaches, such as Kanban and SCRUM, and choose the most suitable for each specific client.
Let’s see why we advise many of our clients to abandon the common waterfall approach and to pay attention to agile development methodologies.
What is the difference between agile and waterfall?
What is the waterfall methodology?
The waterfall methodology revolves around careful planning and the definition of milestones in sequential order before the actual development starts. It is best suited for projects with a clear execution plan, an abundance of project documentation and a carefully defined roadmap. Despite looking great on paper, the waterfall model has one severe drawback – its rigidity: after the planning has been finalized, situational and minor changes to the requirements become a challenging undertaking – almost to the point of not being feasible anymore. Instead, each change will trigger a replanning of the entire project – including all milestones.
What are the benefits of the waterfall?
- The full scope of the project is known from the very beginning and cannot be changed during the development.
- The project includes detailed documentation that clearly describes each development step.
- Development start and end dates are fixed. The methodology does not allow changing deadlines.
- Virtually no customer involvement. This method is especially suitable for industries where customers do not want to dive into the development process but rather desire a finished product without their engagement.
What are the disadvantages of the waterfall?
- Requirements must be clearly captured from the very beginning as it will not be possible to make changes after concluding the planning phase.
- Any disruptions such as incorrect documentation or bugs in the development will result in a project delay as the phase has to be restarted.
- The waterfall methodology does not foster any client involvement, except for the exchange of documentation between the development team and the product owner.
- Project testing occurs only at the end of the entire project, and not periodically along the timeline.
- A sequential approach is not suitable for a large-scale project where the deliverable deadline is too far in the future. Any changes in the business strategy that are inevitable in the long run contradict the very essence of the waterfall method – the inability to return to the previous step and introduce changes accordingly.
What is the agile methodology?
Agile, on the other hand, is suitable for projects with a dynamic structure because of its flexibility. The agile method focuses on adaptive, simultaneous workflows and breaks the scope of work down into iterative phases called sprints. Sprints work well for products that require regular revisions during the development cycle.
At the start of each sprint, the list of requirements is prioritized based on customer feedback. At the end of a sprint, the developers and the customer review and evaluate the work with key findings for future sprints. The different agile methodologies we are using:
- Kanban is a type of agile methodology named after the Kanban board, an agile tool used to divide backlogs into stages, with each task being written on a piece of paper and put into columns with statuses ranging from “Started” to “Finished” as the task is being completed. This helps the production team to coordinate, to distribute and to balance the development efforts. Today, the process is, of course, entirely online.
- SCRUM is another agile methodology. It aims to complete a lot of work quickly. The SCRUM backlog is split into week-/two week-long phases called sprints. Each sprint’s specific task is elaborated upon during its kick-off. After execution, the sprint is then reviewed and its success measured. The team uses a Burnout Chart so that they can track the progress and distribute the backlog between the members. The SCRUM Master plays an important role in helping the rest of the team to control the entire process by assigning tasks to them as well as hosting stand-ups. However, the SCRUM Master never takes project management entirely over.
What are the benefits of agile?
- Faster software development lifecycle. The real power comes from rapid learning and discovery.
- The working scope in a sprint is perfectly clear.
- Focus is put on constant communication with a client, which guarantees satisfaction.
- On delivery, the result will be more aligned with expectations – even if requirements have changed along the way.
- Flexibility to accept changes – you can change any aspect of the project at any time.
- Stimulates the engagement of every team member and allows teams to manage projects efficiently
- Team members have the opportunity to observe and test throughout the project.
What are the disadvantages of agile?
- Agile requires a high degree of customer engagement, which not every client is willing to provide.
- A large number of new edits followed by repeated iterations can stretch budgets and deadlines.
- Agile assumes that each member of the project team has a sense of personal responsibility, without which the principle of self-management is weakened.
Why do we choose agile development?
As stated above, Vasterra chooses agile methodologies for most of our development lifecycles. This choice is based on many years of experience working with different types of clients ranging from small startups to large enterprises as well as government agencies. In the process of collaborating with business analysts and programmers from Vasterra, our clients often expand their initial project requirements, which completely contradicts the essence of the waterfall methodology. To illustrate that better, let’s tell the story of one of our projects where agile and waterfall methodologies clashed with each other.
In a digital world, even the simplest projects often become an opportunity for growth and change, although initially, a client may not even be aware of it. It was with such a seemingly simple idea that one of our Italian clients came to us and asked us to implement his idea using the waterfall methodology. We usually choose to not stick to this methodology, but the client’s company was a large and entrenched business, so we decided to accommodate the client’s wishes.
It was this very development methodology that led to the project scope to creep.
The client’s opinion was that for a project as straightforward as his (simply copying the existing platform), the waterfall will be the go-to approach for project management. However, the client did not take into consideration that a brand-new piece of software will provide them with significantly more business opportunities. Very soon after the project kick-off, we received the first feature change request that contradicted the original tasks. Choosing the waterfall methodology, the client hoped to control the project timeline and budget, but in this case, it was this very development methodology that led to the project scope to creep. Halfway through the project, we had great confusion over priority tasks and misunderstandings on how to implement new features prior to the deadline. Neither we nor the client knew when this project would end and what the expected total cost would be. It became pointless to deny that the waterfall methodology was the anchor that pulled the project into the abyss of chaos. Our team persuaded the client to switch to agile methodologies to better accommodate the dynamic requirements. We rethought the backlog and decomposed all tasks into several milestones and sprints.
As a result, our client received much more than just a copy of the existing system built on modern technologies. Our client was able to address multiple bottlenecks of their business and to access new possibilities for growth.
All these opportunities became available to the client because he assessed the risks and opportunities in time and abandoned the waterfall method, which limited the entire development potential.
How do we use Agile in our workflow?
It may seem that agile only describes the specifics of developers’ workflows, but this is not entirely true. Agile is just a methodology that can be applied to any stage and area of a project – even the earliest ones! As you know, one of the four agile software development values is responding to change over following a plan. Let’s take a look at how Vasterra uses agile methods for discovering the requirements of a new project and its kick-off phase:
- At the very beginning, we are having several calls with our client to clarify the scope of the project, as well as the time frame and budgetary constraints. Our sales and analyst teams understand that the customer can change the scope of work after this introduction call. Moreover, after a successful first meeting, discussions of the preliminary project requirements begin. Those can come in many forms – as job listings, presentation decks, functional or technical specification documents. Experience shows that each client has his understanding of what technical documentation is and in what form it should be drawn up – and we study all the documentation sent to us.
- Our team prepares after every call, a preliminary estimate of the project timeline and budget. After each call with the client, we go back to the documentation and make changes to create the most accurate estimate for the specific project. Following the principle of individuals and interactions over processes and tools, we do not bother the customer by submitting each version of the assessment, but rather wait until we gathered sufficient knowledge to send the final cost estimation.
- The principles of agile development allow us to not only move sequentially but also parallel along with the project tasks. For example, the discovery phase where the business analyst describes the functionality of the platform and helps to shape the market analysis, and the design phase based on a design brief – a form to fill out that a client receives from us – are entirely independent of each other. Agile allows us to work on the implementation of these two tasks simultaneously.
As you can see from the description above, agile allows us to go back and forth between different tasks and different stages as well as to make the edits and changes that are suddenly required during the product development process. You do not have this opportunity in the waterfall methodology since its very essence is to follow the plan directly without the ability to return to previous stages.
At the development stage, Vasterra as well adheres to the agile methodology toolkit: while implementing various features simultaneously, we listen to the wishes of our client and have the opportunity to change or add desired functionality at any stage of the development process. Our project managers prefer to divide the development cycles into sprints of 2-3 weeks. Vasterra believes that the customer is not a passive spectator, but an equal partner, which means that the involvement in the development process of both partners is essential to the project’s success.
What kind of payment model is used in the agile methodology?
At the dawn of development outsourcing when waterfall was the only modus operandi, the payment method was not even discussed. It was a fixed price and only that. Over time, alternatives to this payment model have emerged, including its main opposition, Time and Materials (T&M for short). The selection of the correct pricing is directly related to the selection of the development methodology and must be consistent with the requirements and objectives of the project, as well as the overall costs incurred by the developer. Many companies allow in their practice some hybrids between Fixed Price and T&M, but we here at Vasterra do not consider such options.
A fixed price agreement is a single-value contract whereby the service provider is responsible for completing the project up to the agreed amount specified in the contract. It is a convenient choice in cases where requirements, specifications and rates are clearly defined from the outset, and a client cannot make any changes to the project. Thus, the fixed price is most convenient when using the waterfall method.
Vasterra prefers to use the T&M model because we think that fixed cost models in projects with high uncertainty are fraudulent. We either deceive ourselves by not taking into account some nuances and underestimating the project, or we deceive the customer by quoting a higher price and ultimately causing him a greater amount of risks. We don’t like either of these situations. So we use the T&M method which involves invoicing customers for the actual amount of work done on an hourly basis. Clients are charged only for the actual number of working hours – no more, no less. Since in agile we plan sprints for 2-3 weeks, a client understands what a particular sprint includes and how much time will be spent on tasks during this period. If something does not suit him, he can, for example, ask to remove a low-priority but expensive task from the sprint, replacing it with a more important but less costly one. Thus, the project budget becomes flexible and a client can control the budget better.
The T&M method does not throw a client into unpredictability, as it might seem. Although there is no fixed final amount in the contract, Vasterra still provides a client with an estimate of the hours of work required to complete the project. Detailed terms of cooperation and penalties in case of violation will be specified in the contract, signed by both parties – the client and Vasterra.
Our team values T&M for the flexibility and transparency of the payment method. In combination with the agile methodology, this allows our client to get a modern product in the shortest possible time while allowing changes to the project brief at any time – without a negative impact on the development process.
No matter what methodology development teams use, the outcome will largely depend on the implementation. At Vasterra, we believe in our project managers and developers, so we are happy to see them progress in agile methodologies as they see fit.