Which structure would be most appropriate for developing a new highly innovative product that has strict time constraint?

When developing a new software product, your team will need to navigate which development methodology is right for your initiative. In the world of managing software development projects, the topic of Agile vs Waterfall is widely debated. Many thought leaders and Agile enthusiasts in the industry have argued Waterfall is dead, however, traditional organizational environments and processes have led to it still being widely used today. A 2017 report from the Project Management Institute shows that 51% of the organizations surveyed use Waterfall either often or always.

The reality is, each software development project poses its own unique challenges and requirements. It’s not a matter of deciding which development methodology is “the best” in general, but rather which is most suitable for your product’s development so that your team can adopt the appropriate tools, technologies and processes that will result in successful product delivery.

To help guide your product team in evaluating when to use Waterfall vs Agile software development, we’ll walk you through the advantages and disadvantages of these two popular methodologies and the circumstances where it may be more suitable to use one over the other…or even combine the two!

The Waterfall Development Methodology

Waterfall development methodology, as its name suggests, is a stepped software development approach that has a prescribed set of activities and dependencies. The key characteristic of the Waterfall development methodology is that each step in the software development process must be approved by the project stakeholders before the team is allowed to move to the next step, hence the term ‘waterfall’.

The Waterfall development process generally looks something like this:

1. Gather and document all requirements up front
2. Design
3. Development
4. Testing
5. Deployment/Delivery

Your end result is one large final outcome/product.

Pros of a Waterfall Methodology

There are reasons why product teams continue to use the Waterfall development methodology, even with the recent rise of Agile.

1. It’s a well-defined methodology that has been used in all business verticals. It’s a tried and true methodology that is pretty straightforward and expectations are clear.
2. The methodology defines what you are building to a very detailed level at the beginning of the process. This makes setting deliverable dates, start/end dates, milestone planning, as well as the team’s ability to track progress much easier.
3. Developers and testers can focus on writing code and writing test cases. They don’t have to work with stakeholders to determine what the product requirements are.
4. What the team is going to deliver is more predictable. Because the product requirements are documented and approved prior to the beginning of development, there is a commitment to deliver a specific set of features which makes the final product more predictable.

Cons of a Waterfall Methodology

Although the Waterfall development methodology is structured and straightforward, which is suitable for many product teams, it does have its drawbacks.

1. 1. Defined requirements leave less room for creativity. Defining the requirements at the onset of a project also inhibits the product owner’s ability to take advantage of the opportunities they might see during the development process to adjust the requirements and deliver a better solution.
   2. A waterfall methodology can be costly. Even if the stakeholders are confident that they know exactly what they want, their needs can change or they may not have taken into account an edge case. Defining the requirements in the beginning makes adjusting to changes difficult and expensive. Making changes after everything is built often requires expensive rework.
   3. Requirements can be interpreted differently by different team members. A scenario can exist where different people interpret things in a different way. The relationship between the product owner and the development team can become adversarial when someone’s interpretation of a requirement comes into questions.
   4. Significant effort is expended building documentation and not building product. Requirements must be completely documented and approved before any development can occur.

The Agile Development Methodology

The Agile development methodology takes a collaborative approach to software development where requirements and solutions evolve through iterations. Agile software development relies on self-organizing, cross-functional teams discovering and building a solution using an iterative process to discover and build the solution, as opposed to the traditional Waterfall method that defines and plans the entire project before any development work begins.

The Agile development process generally looks something like this:

1. Establish a few initial requirements
2. Design
3. Develop
4. Test
5. Deploy
6. Evaluate the resulting micro outcome (ie a product feature)
7. Collect feedback on what’s been presented thus far
8. Establish new requirements for next sprint based on feedback & repeat the micro outcome cycles until you achieve the final desired product

Pros of an Agile Methodology

So what does Agile have to offer over more traditional software development methodologies like Waterfall? There must be a compelling reason to use the Agile methodology beyond the notion that it’s the ‘latest and greatest’.

1. Agile offers flexibility. One of the foundational elements of agile is that the methodology offers a flexible approach to software development. Priorities and requirements can easily be adjusted throughout the project to meet the needs of the stakeholders.
2. Agile empowers the team. The cross-functional team works as a unit to define, design and build the software product. The team is expected to be self-organized and is not directed by a manager. This allows team members to define and deliver their own work as they see fit. The team is given the responsibility to deliver the project, which empowers them.
3. Time to market is accelerated. With Agile projects, there is more focus on what needs to be done and less of a focus on planning and documentation. The team’s energy is spent on developing the software product and delivering working software with each iteration or sprint.
4. Learning is encouraged and embraced. Learning is part of the process – the product is defined as the team iterates. This allows the team to learn, adjust course and improve through the project. Sprint retrospectives, a process fundamental to Agile, are used to gather feedback from the team on how they can improve to deliver software more quickly and with better quality.
5. More opportunity for creativity exists. Agile works really well when the product vision or features are not well defined. Agile allows product owners to adjust requirements and priorities along the way to take advantage of opportunities and ultimately deliver a better product to all of the project stakeholders.

Cons of an Agile Methodology

Although Agile presents some appealing benefits, it’s not the perfect development methodology for all software product initiatives.

1. The outcome and timeline are less predictable. Agile uses an iterative approach to software development which allows the product owner the opportunity to be flexible with the project scope and timeline. This means at the project onset the end date and scope may not be known and scope creep is possible.
2. The customer (product owner) must invest time in the project: A key element of Agile development is the participation of the product owner in the project. The product owner is a member of the agile team and must be prepared to devote the time necessary to ensure the team has the information necessary to build the product.
3. Documentation is not a deliverable of Agile. In a regulated verticals, such as healthcare, documentation is required. Documentation is not produced during an Agile software development project.
4. A trust relationship must exist between members of the team. It takes time to build trust amongst team members if delivering a product using an Agile methodology is a first time experience for your organization. Product managers and the rest of the team need to work closely together when working using Agile and so building that trust to deliver is crucial.
5. Re-work is inevitable with Agile. Things change all the time when developing using an Agile methodology, so expect that code will need to be refactored.

Deciding Between Waterfall and Agile for Your Project

There are a number of factors that should be considered before a methodology is adopted – we’ve summed them up to help you decide which is more suitable for your project.

Requirements and Regulations

Many Initial Product Requirements & Strict Regulatory Requirements: ✅ Waterfall

If your project has strict regulatory requirements and there is little room to make changes, this will push you toward a Waterfall software development methodology.

Few Initial Product & Regulatory Requirements: ✅ Agile

If your project has few initial requirements and doesn’t need to meet strict regulations, an Agile development methodology will result in project creativity and decreased time to market.

Existing Organizational Processes

Strict Processes in Place: ✅ Waterfall

If you’re in an organization that has strict processes that they have to adhere to, trying to introduce Agile processes cross-functionally could be challenging, and so the Waterfall methodology will be more suitable.

Lenient Processes in Place: ✅ Agile

If your organization doesn’t have strict processes to follow and you have the luxury of being able to work flexibly, then Agile offers enough benefits to introduce the methodology.

Product Owner Involvement

Low Product Owner Involvement: ✅ Waterfall

If the product owner doesn’t want to be very hands-on, a Waterfall approach allows for involvement only during milestone project check-ins, especially since requirements and project expectations are defined in detail from the get-go.

High Product Owner Involvement: ✅ Agile

If the product owner wants to be more hands-on, an Agile development methodology allows for the product owner to be deeply involved. The product owner is a member of the team and is the owner of the product requirements. The product owner ultimately makes all decisions on the scope and the functionality of the product.

Nature of the Project

Enhancement to an Existing Product: ✅ Waterfall

If your team is delivering an enhancement to an existing legacy product where the features are well defined and must interface with known or existing products, then Waterfall may be more appropriate.

Greenfield Product: ✅ Agile

If your team is trying to build something innovative that does not exist in any form today, these types of projects are served well by an Agile software development methodology. It allows the product owner to discover the project’s features and requirements in an iterative way.

Timeline

Fixed & Firm Timeline: ✅ Waterfall

If the project timeline is fixed and can not be moved, Waterfall will offer a more predictable outcome.

Short, Flexible Timeline: ✅ Agile

If you need to get the project delivered in a short amount of time, Agile is the appropriate choice here where action and getting things built is more important than documentation and process.

Budget

Fixed, Inflexible Budget: ✅ Waterfall

If the project budget is fixed and can not be increased, Waterfall will offer a more predictable outcome.

Budget With Wiggle Room: ✅ Agile

If you do have some budget flexibility, Agile prioritizes features and speed to market over strictly sticking to a budget. Sometimes a new, valuable feature will be discovered during Agile development, but will require a little extra time and money to execute. If this works for your team, then Agile is best suited for you.

When to Use the Waterfall Methodology

The Waterfall methodology prevails when the project is constrained by cost and/or time, and the requirements and scope are well understood. In these cases, the Waterfall methodology provides a set of processes that are built on the principle of approval of the previous phase.

The bottom line is that the Waterfall methodology does a better job at providing a well-defined feature set within a constrained budget or timeline.

When to Use an Agile Methodology

Agile wins the day when the product team is unsure at the onset what needs to be built or they wish to discover what should be built based on adjustments they make along the way. Agile will produce more features in a shorter period of time and also gives the team more flexibility throughout the process so that they can take advantage of opportunities as the project unfolds.

Using a Hybrid Development Methodology

At this point, you might be thinking,“Is there a way I can combine both Waterfall and Agile when developing my product to leverage the benefits of each?”. It’s actually quite common for product teams to use some combination of both Waterfall and Agile development methodologies in order to deliver a solution in a way that optimizes the team’s time and resources and maximizes end user satisfaction. The PMI report mentioned earlier states that about 20% of the surveyed organizations’ projects completed within the last 12 months have used a hybrid approach to managing development. KPMG recently researched the adoption of agile project delivery across 62 organizations in both the Dutch and Belgian markets and found that 85% of respondents strongly believed that in the coming years, most organizations will operate in a hybrid environment. This research found that most organizations are currently working to implement Agile and are taking different routes to do so based on the processes that work for each individual organization. For example, some organizations deploy a hybrid model where the overall project phases follow a Waterfall approach to get to an approved design. Then, Agile methodologies are used during the development phase and product development concludes with a period for testing and integration.

Here’s an example of what a hybrid software development methodology could look like:

1. Gather and document all requirements up front
2. Design
3. Development
4. Test
5. Get feedback on what’s been produced thus far (identify changes that need to be made or valuable additions that fall within the outlined requirements)
6. Implement that feedback, develop, test, and prompt for further input. Continue this loop until stakeholders are satisfied with the product.
7. Deploy

Using Agile in Regulated Environments

It’s important to note that the benefits of an Agile development methodology can still be reaped even if your team is taking on a project that succumbs to strict regulation. Agile can still be used as a software development methodology for highly regulated projects – there are just some modifications that will need to be made and documentation artifacts will need to be retrofitted as changes are made to the product. The documentation, and documentation review and approval process, will need to keep pace with the software development, but don’t let this shy you away from using Agile.

As a company that specializes in healthcare software development, our teams constantly take on projects that must meet an array of healthcare regulatory requirements and security standards. Yet, we often deploy an Agile development methodology that is adjusted to meet these specific requirements. At the end of the day, you need to evaluate the workflow, processes and structure of your collaborating teams, the budget that you have, and timelines to determine if either Waterfall, Agile, or a “wagile” hybrid works best for you.

When determining the most appropriate project management structure considerations need to be made at the organizational level and at the project level True or false?

Which of the following is a factor that should influence the choice of project management structure?

Which of the following cultural characteristics relates to the degree to which employees identify with the organization?

Which of the following is a disadvantage of a functional project management organization?