Software development is more than just coding; it's about crafting digital products that require multiple creators working in collaboration with stakeholders. With so many people involved, how can we collaborate effectively to accomplish the creation of a new software application?

This is where development methodologies come in.

A development methodology is a framework within which digital products are created.

In this post, we'll review in detail one of the most successful development methodologies in software development: 🌊 Waterfall, and how to apply it to the development of a new technology paradigm: ᯅ Spatial Computing.

In this post we’ll go over:

1. What is Waterfall software development methodology?
2. The different phases in Waterfall:
   1. 🔭 Discovery
   2. ✏️ UI/UX Design
   3. 👨‍💻 Development
   4. 🧑‍🔬 Testing
   5. 🚢 Deployment
3. How to estimate Waterfall projects?
4. Benefits and risks of Waterfall methodology.
5. Ideal scenarios to use Waterfall.

Let’s go 🏄.

What is Waterfall Software Development Methodology?

The Waterfall methodology is a long established framework in which most of the world’s most ambitious projects are built. Waterfall is the standard method in which the architecture, engineering and construction industry build projects. The process revolves around predefined stages, requiring the involved parties to approve the completion of each stage before moving on to the next.

In software development, these phases are:

1. Discovery

Also known as requirement analysis, this phase is where the involved parties understand the project’s requirements, goals, constraints, and domain of knowledge. This stage is where conversations, brainstorming, analysis, and research take place. The conversations in this phase revolve around understanding:

• What are the business goals of building the product?
• Who will be using the software, and what value does it add for the user?
• What problem is the software trying to solve? How is this problem being solved today?
• What is the long-term vision for the impact of the product?

The discovery phase represents a multilateral mindset alignment among all involved parties. Through these conversations, all stakeholders begin to gain a better understanding and align the vision for the entire project.

The magic of a discovery phase is not just to fill out a survey form to answer these questions but to engage in open conversation, allowing ideas to have s*x. It is in this dynamic collaboration that deep discovery and insights occur, laying the groundwork for the project.

With the insights gathered during the initial conversations, the goal is to create a project execution plan that covers:

1. Description of the product.
2. Business goals.
3. Scope.
4. Development schedule.
5. Risk assessment and mitigation plan.

Once all stakeholders are in alignment with this project brief, we are ready to start the next phase.

2. UI/UX Design

This phase focuses on exploring and designing the digital product outlined in the Discovery phase project brief. It involves dynamic collaboration among all stakeholders and requires multiple stages to complete.

As an example of a Waterfall design phase, let's examine the case study of VisionWEARx, a startup offering virtual reality solutions for screening and diagnosis of dyslexia. We collaborated with the startup's founders to transform how dyslexia tests are conducted, redesigning paper-based tests into a virtual reality testing tool.

The UI/UX design phase follows the following sequence:

1. 💡Concept Design
2. 📐 Design Architecture
3. 🔲 Wireframe Design
4. ✏️ Visual Design
5. ⚠️ Mitigate Key Technical Risks

1. Concept Design

A concept design is an abstract visualization of the digital product's potential functionality. It serves as a starting point for imagination, aiming to align a visual reference among all stakeholders.

Teams can create these manually or leverage generative AI tools like Midjourney and Dall-E to explore multiple concepts. These tools introduce speed to the iterative processes of exploring visual representations of ideas.

Below are some concept designs illustrating how we envisioned VisionWEARx being used by students for dyslexia screening and diagnosis tests.

2. Design Architecture

This phase details the software's functionality. It involves creating a visual diagram that outlines the software's usage flow, features, and capabilities. The objective is to clearly define the software's capabilities.

For VisionWEARx, we identified the need for two software applications:

1. A virtual reality app for patients.
2. A controller tablet app for professionals to conduct tests.

We created Design Architectures for both software applications:

🥽 Virtual Reality App

• Used by patients.
• The Home menu would allow access to:
  • Pairing with Tablet companion app.
  • General Screening test for learning disabilities.
  • Dyslexia diagnosis test.
  • Irlen diagnosis test.
  • Other future tests.
• The VR app should have configurations of tests to control colors, typographies, and the environment the tests would be conducted in.

📱 Tablet Companion App

• Used by professionals.
• The login to enable access to the professional’s patients.
• A Home screen with access to:
  • Pairing to VR headsets. This would connect the tablet to a VR device to control and conduct a session.
  • Testing session where the professional could choose a test to conduct with a patient.
  • Manage patients and see test results with recorded video sessions.
  • A general dashboard with additional stats.

The Design Architecture outlines all core features and capabilities of the applications, including a high-level app flow of navigation between components.

3. Wireframe Design

A wireframe is a skeletal design of a product that defines its layout functionality without considering visual aesthetics. The goal is to detail the user experience, defining how the app works.

In VisionWEARx, we designed all screens for both the virtual reality app and the tablet controller app. Laying out all screens enabled stakeholders to role-play the app's usage.

🥽 Virtual Reality App

📱 Tablet Controller App

The wireframe phase often reveals details not considered during the design architecture. This iterative process helps uncover the intricacies of how the software will function.

4. Visual Design

With a clear understanding of the software's use, functionality, and operation, we begin the visual design phase. This phase defines the software's visual aesthetics, including the overall look and feel, colors, button styles, and typography. A successful visual design phase depends on the clarity of previous stages.

In VisionWEARx, this phase focused on applying visual aesthetics to the approved wireframes, which were based on startup and partner insights as well as design best practices for reading text in virtual reality.

During the visual design phase, we ensure that all stakeholders are aligned with the expectations for the final product before proceeding with its implementation.

🥽 VR Application

📱 Tablet Companion App

This Visual Design will act as the reference and source of truth for the product as we commence development. The more thorough the details are defined and confirmed during this phase, the lower the risk of encountering costly pivots during the development phase.

5. Mitigate Key Technical Risks

Before the official software development begins, validating the technical feasibility of planned features is crucial. Creating small prototypes to validate key risks can save significant effort and mitigate critical project risks.

In the case of VisionWEARx, the primary risk we identified was the mechanics of the writing system in VR. Our initial research identified potential hardware solutions, such as the Logitech VR Ink Pilot and the Wacom VR Pen, prior to the release of the Meta Quest Pro stylus controls.

We discovered that the Wacom VR Pen was merely an internal concept project, not ready for the market, and that the Logitech VR Ink pen was compatible only with Vive, which requires a full gaming PC to operate, a non-viable option for the business context.

So, we then set out to build a technical prototype to determine if we could create our own writing system using VR headset controllers.

This prototype confirmed that writing in VR was feasible and that all features outlined in the final UI/UX design were technically achievable. Once all stakeholders are in agreement and aligned with the expectations for the final product, and key risks have been addressed, we are ready to start development.

In scenarios where a technical risk proves to be technically impossible, it may be necessary to pivot the design of the software. This decision should be made in collaboration with all stakeholders, and priorities should be evaluated to understand the business context. In the case of VisionWEARx, the fallback plan was to have writing done on an iPad and reading done in VR. This was far from ideal, but it would have allowed us to progress with early clinical trials while waiting for the VR hardware to advance. Interestingly, the Quest Pro launched soon after the completion of the pilot project, which introduced a stylus writing controller for VR.

3. Development

In the field of software development, there is no defined rulebook on how to code. There are infinitely many “correct” ways to implement any system. However, we can align with a framework that elevates the chances of successful implementation in a business context.

When it comes to managing enterprise software development, here are some additional guidelines:

1. ⭕ Complete a minimum usable product as early as possible.
2. 🔄 Involve stakeholders throughout the entire process.
3. 🏃 Work in a series of sprints.
4. 🏈 Encourage multidisciplinary team effort.
5. 🌱 Invest in environment setups.
6. 📄 Centralize the sources of truth.

1. Complete a Minimum Usable Product as Early as Possible

One of the most important skills for engineering managers is managing prioritization, which can define the success or failure of a project. The guiding principle at the start of a project's development should be to complete a minimum usable product as soon as possible, then continue building one new module at a time.

The Pareto Principle, also known as the Power Law, is a good framework to follow. In this context, the principle suggests that 20% of the functionality of the software delivers 80% of the value. The goal in prioritization is to focus on the core 20% of functionality first and, upon completion, work iteratively on the remaining 80%.

Prioritize completing the app's core functionalities through a vertical slice approach before developing secondary features. This method addresses a common critical mistake in the industry where developers work on multiple parts of the software simultaneously, often leading to an unfinished product by the end of the project timeline.

Instead, focus first on the core feature of the product. By completing a vertical slice of the central element of the software first, you achieve early success and continue building upon this success until the project is fully completed. This approach minimizes execution risk, builds trust among stakeholders, and facilitates early internal testing during the development phase.

2. Involve Stakeholders throughout the Entire Process

Communication between stakeholders is a key component in the success of a project. It is highly recommended to establish predefined weekly meetings with operational stakeholders to synchronize on progress, discuss challenges, address questions, and ensure general alignment on the development's progress.

For the internal development team, a weekly meeting is also highly advisable as it fosters individual accountability for weekly progress and enables each team member to focus on completing modules for this meeting, centralizing non-urgent communication into one weekly instance.

Regarding daily stand-ups, while some companies adopt this practice, it often feels like an unnecessary protocol that demands synchronous(real-time) communication, the most costly type of communication. In Waterfall development projects we recommend daily stand-ups only when necessary and prioritize the use of asynchronous communication for day-to-day collaboration.

3. Work in Sprints

Sprints divide a long project into subdivisions with defined starting and ending points. This creates visibility for short-term goals to work towards, with clear expectations and objectives. Working on long-term projects may sometimes feel endless, which can be demoralizing for the execution team. Sprints introduce the opportunity to start and finish tasks on a more short-term basis, introducing multiple wins during the development of a project.

We recommend the simultaneous use of two types of sprints:

• 6-week sprints for modules and large features.
• 2-week sprints for tasks.

Sprint deliveries offer the chance to regroup, evaluate progress, and test new builds. They provide opportunities to reflect on and assess progress, risks, and challenges.

4. Encourage Multi Discipline Team Effort

Instead of viewing the development phase as a large hand-off from designers to software developers, this phase should be considered a collaborative multi discipline effort. During the development phase, most of the heavy work is done by software developers, but it is crucial to have other disciplines participate, ensuring a multidisciplinary collaborative effort.

These other roles include:

• Designers to review front-end implementation and assist with implementation decision-making.
• Testers to enable software developers to focus on engineering challenges instead of manual testing of an implementation.
• Engineering managers to collaborate on implementation decision-making and prioritization.
• 3D design team working with technical artists on integrating visual 3D content into the application.
• Subject matter experts for access to questions and reviews of implemented modules.
• Final users to showcase previews for quick reviews and feedback sessions.

5. Invest in Environment Setups

When we think long-term, we invest time and effort today to reap benefits tenfold in the future. In software development, these investments can include:

• Setting up CI/CD pipelines to streamline the app-building process and speed up build times.
• Creating sandbox tools to accelerate iteration processes.
• Implementing external, low-effort content management systems to enable other stakeholders to edit app variables without the need for rebuilding, for example, via databases.
• Developing centralized, reusable code-bases for scenarios that repeat across projects to streamline the re implementation of repeatable challenges.
• Streamlining design pipelines with 3D software like Blender, eliminating the need to manually re implement 3D assets and allowing a team to quickly iterate between both software.

The goal of building a base environment is to make the development process more streamlined with faster iteration loops. The more we invest in the environment, the more enjoyable it becomes to work in the garden.

6. Centralize Sources of Truth

When it comes to the flow of information within a team, it is essential to centralize all knowledge into a single shared point that can be accessed by any stakeholder at any time. Examples of this mindset include:

• Centralizing all relevant links in one place.
• Ensuring code is always pushed and available in real-time on Git.
  • A stable branch should always be available for team members to access the latest working version at any time.
• Executing design in real-time collaboration tools like Figma.
• Documenting all research and learning.
• Recording and sharing meetings.
• Documenting any recurring task or manual procedure as a guide, ideally in video format using tools like Loom.
• Documenting database structures to be editable by all operations stakeholders.
• Establishing processes for building and deploying updates.
• Defining processes for setting up the development environments.

All this knowledge and information should be centralized in tools like Notion to enable teams to operate asynchronously.

These guidelines serve as a roadmap for developing a successful project. Every project is unique, with its own context and stakeholders. These guidelines help align mindsets to reduce the risk of implementation, creating a win-win scenario for everyone.

4. Testing

Testing, more accurately termed quality assurance, focuses on polishing to achieve world-class software product quality. Excellence in the execution of each phase is critical, not only in this final testing phase. Testing encompasses multiple verticals, including:

🔬 Design Reviews

These are instances when the design team reviews the software's implementation of front-end components. Some design aspects may be left open to implementation during the design phase, especially when designing 3D products on a 2D canvas like Figma. This is natural, as these details are specific to implementation..

Design reviews enable designers with high aesthetic criteria to refine implementation details that might not be as evident to software engineers. This collaboration between developers and designers demonstrates how two distinct creative mental models work together to refine a product.

🤏 Usability Testing

Usability testing polishes up user experience design decisions based on end-user feedback. Some minor aspects may have been overlooked during the design phase, which can be addressed in this phase. Usability refers to the general user experience when using the app. It enables designers and stakeholders with high aesthetic sensibility and a focus on product usability to provide key input.

🐛 Bug Fixing

Bugs, which are software defects, are a natural part of software development. Many bugs are left unresolved during the development phase to focus on higher priority tasks, such as developing new features. Towards the end of the project, many of these remaining bugs are reported and fixed.

During the testing phase, it is crucial to test the app on all supported hardware platforms to identify any device-specific bugs.

🏋️ User Testing

User testing involves having first-time users, who are not stakeholders in the project, test the application. A general best practice is to place the software in the hands (or eyes) of an end user to observe additional insights on usability and general feedback.

Testing with five first-time users usually provides 80% of all user feedback. Prioritize qualitative feedback over quantity. Ask users to verbalize their thoughts as they use the application and record everything for future review.

Testing should not be viewed as a complete handover phase from the development team to a testing team. It should be a collaborative effort that begins during the later phases of the development cycle.

5. Deployment

Depending on the project's context, the deployment phase can range from a simple executable build delivery to a more complex product launch. Typical tasks in this phase include:

• Delivering builds through the appropriate distribution channels.
• Creating deployment documentation, which summarizes project execution, delivery, and a recap of all objectives accomplished.
• Creating marketing material for communicating the project outcome to external stakeholders.

For enterprise applications intended for internal company use, the ideal distribution platforms are content distribution software like ManageXR or ArborXR. These platforms enable quick distribution of an app to multiple devices and control of this setup through a dashboard.

For distributing to end-users, we can utilize the specific distribution channels of each platform. These are specific to each hardware provider: Meta, Apple, Magic Leap, Microsoft Hololens, Pico, and Vive. These native options for distribution are effective but require specific publishing processes for each development platform.

Once the software distribution is complete, the development process can be considered finished, marking the beginning of the software's lifecycle in a business context. However, this is not the end of the software's life. This is when the business actually starts to use the software. Most software applications undergo years or even decades of continuous development. The launch of a first project is hopefully the beginning of a long-term collaboration, iterating based on market needs, user feedback, and the natural evolution of the software and hardware ecosystems.

How To Estimate Waterfall Projects?

Software development is notorious for its lack of accuracy in estimating execution efforts. This is primarily due to the unknowns inherent in software development and the fact that there are infinite correct ways to develop a software application. It's not uncommon in the industry to hear stories of estimations taking three to five times longer than initially expected.

A few key initial considerations based on our experience:

• Long projects are impossible to estimate accurately; it’s like throwing a dart in the dark.
• Small projects require more discovery and time to estimate than to actually develop.
• The sweet spot is medium-sized projects: 6-24 week projects.
• Projects shorter than 6 weeks should be developed using Agile methodology, as speed is of the essence for such a short time frame. (Our guide for Agile Development is coming soon.)
• Projects longer than 24 weeks should be divided into multiple independent projects, as the risk of accurately estimating a project longer than 6 months is extremely high.

Here’s our recommendation:

1. Based on the discovery phase and the business context of the project, guesstimate a length of implementation in segments of six weeks: 6, 12, 18, or 24 weeks. This time-frame will serve as a benchmark for execution.
2. Evaluate the resources needed for the project within the available time-frame. Some projects may require more 3D design, while those with more complex backend need more development resources. Estimate a budget for the time-frame, taking into account the five phases of the waterfall development methodology. Add a buffer to the estimation to account for each specific project’s risks and unknowns.
3. During the design phase, design a product that accommodates the budget and time-frame constraints. Clearly outline what the core features are and what are secondary, nice-to-have features.
4. During the development phase, focus on maintaining the budget, the timeframe, and the core priorities of the project. With budget, time, and scope, we can fix two but not all three. If we opt for a flexible scope, we can deliver on the three main business priorities: budget, timeframe, and a fully working product that meets business goals.

During development, prioritizing core features usually guarantees a successful project as soon as possible. Then, continue building secondary features until the time-frame and budget are completed. This creates a win-win situation for all stakeholders as we achieve the objectives of the app within a defined schedule and budget.

The key to this approach is aligning expectations with all stakeholders and having a deep understanding of the business objectives of the software. Delivering the core functionalities of the project is crucial, and being aligned with these priorities during development will enable a successful delivery within the time and budget available for the project.

Benefits and Risks of Waterfall

The Waterfall methodology is not the only methodology for developing software. Another famous development methodology is Agile (Guide coming soon). Since the mid-2000s, when Agile started to gain popularity with the Agile Manifesto and the lean startup generation, there has been an ongoing debate between Waterfall and Agile (Coming Soon: Agile vs Waterfall in Spatial Computing Development).

Let's review the benefits and risks of Waterfall:

🥗 Benefits

1. Elevates the Probability of a Successful Implementation

One of the key benefits of the Waterfall methodology is that it maximizes the probability of achieving a successful implementation. This is because working towards a clearly defined vision is much easier and less risky than working without a clear direction. Knowing the exact destination with precision and detail reduces the risk of getting lost or confused along the way.

In contrast, under development methodologies like Agile, the execution team and stakeholders don't have the details of exactly what they are building. While this approach has its benefits, it introduces higher levels of risk in achieving a successful implementation

2. Improves Communication Between all Stakeholders

Waterfall enhances communication among all stakeholders by aligning the expectations of the final product into a detailed source of truth early in the project lifecycle. The execution team can work together towards a clear and centralized goal, and day-to-day decisions are simplified by having a clearly defined product before starting development.

3. Minimizes Risks Unexpected Outcomes

Waterfall minimizes the risk of encountering surprises and unexpected outcomes during the project's development. A thorough discovery phase should focus on mitigating any potential surprises during the execution phase. This focus on reducing risks enables stakeholders to arrive at the expected destination from the start of execution. Having a clearly defined vision, thorough risk mitigations, and an approved product early in the process ensures that all stakeholders can expect the outcome defined at the start of the project.

These are key benefits that other methodologies, like Agile, do not prioritize. When done correctly, with a depth of focus in the discovery phase and executed by a senior team, Waterfall provides the framework with the least risk of failing to accomplish a successful execution. In new niche technologies like Spatial Computing, reducing these risks is critical to avoid failed projects.

⚠️ Risks

1. Developing a Product with No Product-Market Fit

A recurring theme in the mobile startup ecosystem was that startups often built products that no one actually needed. This observation is the main thesis that sparked the Lean Startup movement, which has garnered massive support but also faced some valid criticism. The Agile methodology prioritizes reducing this risk by introducing a continuous pivot throughout the entire development process. In the Waterfall methodology, a few ways to minimize this risk are:

• Risk Mitigation 1: Conducting a thorough discovery phase to understand the core business and user needs.
• Risk Mitigation 2: Working on projects with shorter scopes. Instead of developing an 18-month project in one go with the Waterfall approach, divide the project into shorter increments of 6 months each. This strategy reduces risks by providing multiple opportunities to deploy the software into users' hands and using this feedback and learning in the discovery phase of the next project stage.

2. Lack of Flexibility to Pivot

Waterfall's main shortcoming is its lack of flexibility to pivot during development. Often, teams discover new findings during the development process or in early testing. Other time they may encounter technical challenges that require redesign aspects of the product. Due to the nature of Waterfall, pivoting the project during development can be very costly and require a reorganization of whole development schedule. To mitigate this risk, consider the following strategies:

• Risk Mitigation 1: Work with experts in the technology who know exactly what is technically possible before starting. A veteran team has a good grasp of what is technically feasible and has encountered many of the repeated challenges in the space.
• Risk Mitigation 2: Invest time in mitigating risks by creating technical prototypes to validate key technical risks during the discovery phase. In Waterfall, it is critical to confirm technical feasibility before proceeding with development.
• Risk Mitigation 3: Focus on shorter projects. Projects with a timeframe of 6-24 months enable stakeholders to introduce agility through multiple shorter projects. Each completed project provides new insights and learnings that can be applied to the following version.

Ideal Scenarios to Use Waterfall

Ideal project lengths for Waterfall are 6-24 weeks. Longer projects present too high a risk for accurate scoping, and smaller projects often take more time to discover than to actually implement.

Some ideal project types for this methodology include:

🧑‍✈️ Pilot Projects

Many relationships with long-term clients at Treeview start with a first pilot project. This serves as an opportunity to build trust through the execution of an initial project. Choosing a trusted development vendor for a project places the client in a high-risk scenario, so being able to reduce these risks is key.

A pilot project is a great scenario for the Waterfall development methodology because it helps align the expectations of all stakeholders. After completing the pilot project, new opportunities can appear to grow the business opportunity. In some cases, the project starts to transition from a pilot to a business unit, which can become a very large software project. This transition is a great moment to switch to Agile to provide flexibility and speed for the future growth of the project.

Pilot projects executed in Waterfall reduce the risk of failure and provide a smaller investment for a first step in this technology, which may open the doors to future growth and business opportunities.

🏛️ Enterprise Software

Enterprise software is ideal for Waterfall methodology due to the typical enterprise structure of budgeting approval through statements of work, often used by corporations when working with vendors. Enterprise decision-making is usually based on KPIs and objectives that align with the direction of senior management and the leadership of the organization. This structure aligns with project initiatives that require defined outcomes to approve initiatives.

With Waterfall methodology, the goals of a project are defined as part of the discovery phase, and the rest of the project execution aligns with these goals. This allows a project to align expectations with all stakeholders involved from the start, ensuring all stakeholders have clear expectations of the end results and thereby limiting misunderstandings and risks.

Conclusion

Since the popularization of Agile software development in the mid-2000s, there has been an ongoing debate between Agile and Waterfall. At Treeview, we have developed projects using both methodologies, and from our experience, we have found that neither is superior to the other; they are simply different approaches that prioritize different values.

When it comes to building software for enterprise clients, we've learned that Waterfall is superior in this context because it includes additional layers of communication and expectation alignment among all stakeholders. This helps to reduce the risks of execution and increases the chances of delivering on time and on budget, which is critically important in this type of development.

If you’re looking for a senior development team specialized in AR/VR, let's schedule a call to discuss your project details.

See you next time!