You came up with this mind-blowing product idea which you’re certain is going to revolutionize the market. Now all you have to do is turn that idea into reality. Easy! No, not really – achieving reality requires a lot of decision making!
Table of contents
The first step is determining whether you want to develop your product internally or find an external partner to work with. Product development agencies follow different project management methodologies. Effective product development often relies on selecting the right approach.
What are your options?
Agile and waterfall are the most widely used methodologies. They each have a very different approach to product development. Which works better for app development, agile or waterfall?
Waterfall methodology vs. agile - the origins
Let’s start with a short history lesson. Waterfall was born in the 1970s and is known as the traditional method of software development. It revolves around three key principles: minimal customer involvement, detailed documentation, and a sequential structure. It was originally mainly used in non-software industries like manufacturing and construction.
Agile came to life in the early 2000s, with the aim of addressing waterfall’s deficiencies. Flexibility, strong customer involvement and an iterative structure are what characterize agile. It’s commonly used in the software industry.
The agile manifesto nicely summarizes the differences between agile and waterfall – you can find it here.
Agile vs. waterfall project management - which one is better?
Agile vs. waterfall – the battle of the giants. It might seem difficult to decide which approach to follow without knowing much about them. Here is a quick comparison of both methodologies to make this decision easier!
Setting project requirements
An advantage of agile development methodology over waterfall is that product requirements can be modified at any stage of the development process, even after the planning has been completed. In waterfall, the project requirements are defined right at the start. If your vision changes or market conditions alter, you’ll have to start the entire process from scratch to account for the changes.
Imagine a scenario where a company manages their project in agile. During product development, they discover that the feature they worked on relies on an external service, and its price has gone up drastically – this is something they have no control over. Teams working in agile would run a pivot to identify an alternative solution; be it a custom-made or ready-made solution bought from a different provider.
In waterfall, such a turn of events would be impossible. You would have to strictly follow the documentation and stick with the more expensive option which you previously agreed on. Agile puts client and user needs over documentation, as opposed to waterfall.
Product development planning and scope
Waterfall represents a linear process, it’s implemented as one project which is split into phases. A new phase cannot commence until the previous phase is completed. No phase can be revisited; the only way to return to a phase is by starting from the beginning.
One of the primary advantages of agile over waterfall is its flexibility. In agile, product development is based around development cycles called sprints. Product changes can be implemented at any point during product development as opposed to waterfall, which requires fixed product specifications with no modifications allowed.
Waterfall follows a fixed time, price and scope approach – everything is agreed upon before the project starts. Such an approach is designed for companies who know exactly what their expectations are and that they’re not going to change during the development process. Agile usually relies on the time and materials model. What does that mean? For example, if you decide to work with an external partner who follows agile, you’ll only be charged for the actual time the team spent working on your project.
At Boldare, we usually follow the time and materials approach for the benefit of our partners:
- you only pay for the for the accessibility and capacity of our developers or actual working hours (calculated based on the hourly rate or a fixed rate per team member);
- even if the work scope changes, the cost may stay at a similar level (but only if the new features or user stories don’t prove to be more time-consuming than the features that were considered initially);
- we are flexible, which means that we always have a very positive attitude towards changes, even late ones.
However, if our customer requires a digital prototype or has clearly defined business objectives and product specifications, we may discuss a fixed price or scope, eventually.
Approach to testing
Another aspect worth mentioning in our agile vs. waterfall project management face-off is their very different approach to testing. Testing is one of the key components of agile. The product is tested during every sprint as it’s created, which allows developers to quickly spot and eliminate any bugs. This results in faster product delivery and significant cost savings.
At Boldare, we have a code review process which mandates every piece of code be reviewed and approved by at least one another experienced software developer. This, combined with continuous integration, automated tests and other practices, ensures the high quality of our code and helps us to maintain good programming practices in our software. This procedure is one of the most important processes we practice and we give it a lot of attention.
In waterfall, testing is performed after the build phase which can cause serious issues, especially for larger-scale projects. Errors made at an early stage of product development will not be spotted until the product is completed, which will negatively impact its quality.
If your product is complicated, or you’re unsure of what features it should have, choosing agile is always a much safer option.
Customer involvement in product development
By choosing agile, you actively participate in the product development. You and your external partner act as one team. Agile puts a strong emphasis on customer satisfaction; you take part in every stage of the development process.
Waterfall, on the other hand, limits client involvement. The customer is responsible for providing detailed project documentation and this is where their role ends. This frequently results in miscommunication and has a negative impact on product quality.
According to research from the Standish Group, agile has a higher project success rate in comparison to waterfall. Only 9% of agile projects fail. This number is significantly higher in waterfall, at 29%.
At Boldare, keeping our customers satisfied and happy is our top priority, which is why we favor agile. We start each project with a discovery workshop which usually lasts one to two business days. This workshop is when the development team, the scrum master, the graphic designer, and the Q&A analysts meet with the customer to better understand their needs and goals.
Why are product discovery workshops so crucial? Because thanks to them the product owner has the opportunity to explain their (and their decision makers’) expectations and goals regarding the project; giving the team, the chance to understand it better. During such workshops, both sides can challenge the initial idea, talk about potential risks and find solutions or choose a better path for reaching the project goals. A product discovery workshop allows us to build a better product and helps to avoid misunderstandings during the development process.
The shape of the team will be determined based on the customer’s requirements. It might include a customer success guide instead of a QA specialist, for example.
The discovery workshop results in creation of a product canvas that includes crucial product information, the product backlog, user story mapping, and initial time frame. All to ensure fruitful cooperation.
By participating in a discovery workshop, our customers not only meet the team they’re going to work with but they’re exposed to fresh perspectives and ideas. Potential risks and problems are identified early. It also gives the development team a chance to better understand what the customer wants to achieve.
In summary, the purpose of the discovery workshop is to:
- figure out why we want to bring the product to market;
- asses the stage that the product is at;
- provide customers with potential solutions;
- decide on the technology we’re going to use;
- understand the risks, and define what success means to both parties.
- There are no workshops in waterfall, which is a real downside.
Team structure: agile vs. waterfall
Waterfall teams tend to be large with a rigid structure with specific roles assigned to each team member. Each member of the team is accountable for a stage in the development process. The project manager, who acts as the leader, is responsible for the end result of the project. This can lead to less teamwork, as each individual focuses primarily on delivering their own assigned tasks.
On the other hand, agile teams are often small, and have more adaptable skill sets; for example, a developer is also a tester and an analyst at the same time. Even though it’s usually the project manager who is the project leader, everyone in the agile team is held responsible for the project’s success. In agile, teamwork thrives, while all issues are resolved through regular and effective communication.
At Boldare, we don’t have project managers – we have scrum masters who are team facilitators. They manage the development process, ensure everything goes according to plan and resolve problems if any arise. Not having a project manager eliminates intermediaries and allows for more direct communication.
By working with Boldare, our customers not only get a dedicated dev team and a scrum master, but they also get access to our extensive business expertise. Whenever our partner needs support with setting up a product’s metrics, its budget, ROI or any other business-focused or product related KPIs, we offer help through our customer success guide, scrum master or head of development. Why? Since we work together, we feel that it’s also our responsibility to deliver a product that will be beneficial for both sides: our partner, their stakeholders, and us.
Our customers can benefit greatly from our specialized knowledge transfer. What’s unique about working with Boldare is how we assign teams to projects. If you require an MVP, you get a team that specializes in MVP development – this will positively impact the end result.
Communication
Good communication is crucial for effective cooperation. Agile teams put a lot of effort into communicating project progress regularly. The customer is involved in product development from start to finish.
At Boldare, transparency is important – we have nothing to hide. Anyone from the team can verify the project stage. The partner can get in touch with any team member they like – be it the scrum master, the developers, or the graphic designer. Our customers always have full access to the entire team, including their skills.
In waterfall, communication is limited, irregular and not as organized as in agile. Most communication happens during the requirements phase – where the project manager agrees the product requirements with the customer. Once this phase is completed, the customer steps out.
Agreeing on the budget
Setting the budget is one of the most crucial steps in the product development process. In waterfall, the budget is set up front and usually cannot be modified. The agile methodology revolves around flexibility, which also applies to budgeting. You can calculate the budget based on the number of sprints. You can easily agree on how much each sprint is going to cost.
The cost depends on the project’s timeframe. Since scrum teams are made of dedicated team members, they have a set team cost which is calculated as an hourly or fixed rate per person and is the same for each sprint. This makes budget estimation easier and more accurate.
One of the greatest advantages of agile over waterfall is that the budget can be altered – if your product vision changes, so does the budget. For example, if you decide you want to eliminate or add more features, you can, and these changes will be reflected in your budget. This would not be allowed in waterfall.
At Boldare, we agree an initial budget based on the product requirements provided by the product owner. The budget is then adjusted during the discovery workshop and can be changed after each sprint. In agile, the development team and the scrum master are responsible for budget estimations and for finding the most efficient solutions to ensure the project stays within those estimates. The product owner always knows what the budget is. The scrum master ensures the process is transparent and that the product owner has access to all data.
Waterfall vs. agile product development - concluding thoughts
What is the difference between agile and waterfall? The agile approach is suitable for most software projects, especially if you’re unsure of the final product requirements. Agile gives you a lot of flexibility – feature changes are never a problem as modifications are performed during each sprint.
This methodology puts less pressure on getting things right the first time. Thanks to continuous testing, bugs are eliminated early in the development process, which guarantees high product quality and fast market delivery. Usually, the products that are made by agile-fueled teams are a better fit with the user’s expectations and needs, thanks to agile’s user-oriented approach.
The agile manifesto points out that user satisfaction is more important than simply following a development plan and documentation, which is the focus of the waterfall methodology.
Waterfall is more rigid, and less forgiving of errors. Product specifications must be agreed upon up front, and no changes are allowed after the development process starts. It is best-suited for short projects which are well-defined from the beginning.
Overall, agile is a much safer option irrespective of the size and complexity of your project. If you aren’t sure which approach to choose, go with agile!
Share this article:
