Waterfall vs Agile

From the very beggining

We used to use the waterfall methodology for managing our products. It was natural as its easily understood and widely used across different sectors. It's also taught in every management field at universities.

The methodology we follow involves gathering all inputs from the customer at the beginning of a project, which serves as the foundation for the entire project. Any changes or differences are addressed first from a contractual point of view before implementing them in the code. Based on the agreed-upon inputs, we offer a fixed price for the project. To manage the project effectively, we divide it into phases, and the customer pays after each completed phase.

Our step-by-step methodology

Our methodology consists of four phases:

Pre-implementation analysis phase:

In this phase, we conduct a thorough analysis of the customer's inputs, business goals, processes, and marketing strategies. We also determine functional and non-functional requirements and supported devices. This analysis helps us create project documentation, which outlines the proposed solution, sometimes including wireframes. Additionally, we perform a technical analysis to describe the proposed architecture, technology, and database.

Planning phase:

During this phase, we divide the project into technical tasks, estimate the tasks, create a budget, and provide the customer with an overview of the expected costs of implementation.

Implementation phase:

This phase involves working on the graphic design of the solution. We provide the customer with 2-3 iterations of feedback on the design before beginning the implementation of the planned tasks. Throughout this phase, the customer receives periodic updates on the progress of the project, with a final product delivery at the end. Any new requirements introduced during this phase are considered as additional work and must be estimated and approved by the customer.

Maintenance phase:

After delivering the finished product to the customer, we typically agree on an SLA contract and provide ongoing support for the solution over a defined period. If the customer would want to leave at any phase of the project we would have to agree on terms & conditions of cancelation of orders and the contract.

It's doable, but...

We do not say that this approach is completely wrong. It can fits for some small projects, or building the same software solution for every customer. But this is not what we usually do. We build custom software for our customers. We are able to provide rouch estimates based on our previous experiences but the more complicated project is or big it becomes impossible to specify every detail at the beginning of project by us or even by the customers.

Sometimes happened to us that during the development the responsible person from the customer part or their company process changed. Or that when customers finally saw the developed feature or graphic they find out that it needs to work differently or needs to change something due to changes in end users' behavior or in the market. All these things meant changes in the requirements usually of the already developed product. At the end customer was not satisfied with the project because the original requirements were not reflecting the real needs and we were not satisfied with the project because of the growing costs of the project and very hard negotiation with clients about additional resources needed.

Limitations of Waterfall methodology:

• Waterfall is suitable only for some projects;
• It's impossible to specify every detail at the beginning of a complex project;
• It's impossible for the software company to estimate every bit of tasks;
• Changes in the project can occur due to changes in end-users' behavior or the market;
• Changes in requirements can occur during development;
• Original requirements may not reflect real needs;
• Growing costs of the project can cause problems for the client and the software company.

Hybrid model

That is why we slowly started to change the approach with new clients.

In the beginning, we did something between Agile and Waterfall more like a hybrid. Customers were not used to agile and did not trust it much at the beginning so we compromised. We agreed on Fix Timeline and approximate budget based on specified requirements. The difference from the previous waterfall methodology is that we used close cooperation with clients from agile. We divided the delivery into sprints, we did a demo to the customer every 2 weeks and we were working on specifying the requirements at least sprint ahead. The cooperation with the client and their satisfaction with the end product was much better but still, the product backlog grew during the project so the timeline had to move also. The disadvantage of this cooperation was again a lot of time spent on reporting and defending every additional hour we had to spend. It was not a win-win partnership we wanted to have. We knew that the next cooperation had to be purely agile. We reworked our contracts and over the years the Agile methodology and its benefits started to be more known among customers.

Why Agile?

• Agile methodology emphasizes collaboration, flexibility, and adaptability throughout the project lifecycle
• Agile breaks the project down into smaller, manageable chunks and delivers working software early and often
• Agile allows for ongoing communication and collaboration with the client
• This helps to build trust, ensure project remains on track
• By responding to changing requirements, the final product better meets the client's needs and satisfaction.

Starting new cooperation

We prioritize honesty and transparency when starting a project with clients. Rather than promising fixed dates and prices, we provide rough estimates based on initial ideas or specifications.

However, we work closely with the client to refine the end user needs and requirements, and to adjust the scope of the project to fit within a possible budget.

• We believe that clear communication and collaboration with the client is essential to delivering successful projects, and we prioritize working closely with them to refine the end user needs and requirements. This allows us to adjust the scope of the project as needed to fit within a possible budget, ensuring that we deliver high-quality work that meets their specific needs.
• Our goal is always to provide the best possible outcome for our clients, which is why we work closely with them to refine the project requirements and adjust the scope as needed. This ensures that we are able to deliver a high-quality product that meets their needs while also staying within their budget.
• At our company, we understand that project requirements can evolve over time, and we are committed to working closely with our clients to ensure that we are able to adapt to these changes. By refining the end user needs and requirements and adjusting the project scope as needed, we are able to deliver high-quality work that meets their needs while staying within budget.

Our main focus

Our primary objective is to provide exceptional quality work to our clients, and we prioritize this by relying on our extensive experience, expertise, and unwavering commitment to every sprint. We believe that by closely collaborating with our clients and consistently refining end-user needs and requirements, we can deliver high-quality work that is aligned with their expectations. Furthermore, we are committed to ensuring that our clients have complete control over their projects and are free to choose another software provider if they are dissatisfied with our services at any time.

We believe that our success as a software development company is ultimately dependent on the satisfaction of our clients, and we strive to ensure that every project we undertake results in a positive outcome for both parties.

What do we use

From the agile methodologies frameworks we use mostly Scrum but for some projects also kanban. We mostly work in short - 2 weeks iterations and show, discuss and iterate on the results with customers at the end of a sprint. We gather feedback, transfer it to task and prioritize based on agreement with the customer. If a customer needs a sudden change of direction its not a problem because in agile we are not bound by any fix contracts or any rigid processes. We just clarify the needs with the customer and plan the change from the next sprint if necessary.

So why do we prefer Agile over the Waterfall?

• Because we care about what we are developing we care about the end product.
• We prefer close cooperation with customers to create working & meaningful products over endless negotiation about every minute spent on a project.
• We prefer agility and flexibility over blindly following original plans