As contractors are well aware, project-management methodologies can dictate whether a project is successful or not. In a similar fashion, software development also requires a well-thought-out approach to creating new products and features. In this article we’ll outline the two most common approaches to software development, and why they matter, and we’ll also take a look at an example of Bridgit’s agile methodology at work.

Does the development methodology really matter to the end user?

In short, yes. Or, at least it should. As the end user of a software product, you should ask yourself – “Do I want my software provider to be predictable or do I want my software provider to be adaptive to my needs?”. For construction projects, predictability reigns supreme. With software, however, adaptive development helps to deliver better outcomes, faster.

This is where the development methodology plays a big factor. With construction undergoing a massive digital transformation in the last decade, and processes being digitized across the board, working with software providers that can recognize change and adapt their products should certainly be considered when evaluating software and technology.

The two most common project methodologies

The most commonly used methods for software development today are the Agile and Waterfall models. While the Agile model is becoming more popular, there are certainly detractors that will stand by the traditional Waterfall model. 

The Waterfall model

You may be familiar with the waterfall model as it’s traditionally used in construction and manufacturing. However, it has made its way into the software-development world as well. The waterfall model is characterized by strict and linear principles. For example, the waterfall model dictates that a project starts in Phase 1 and doesn’t progress to Phase 2 until everything in Phase 1 is completed. Projects start at the top and work their way down, like a waterfall. 

While this model certainly works best for construction projects, software development is a completely different monster. Customer needs can shift quickly. The last thing a software development team wants is to spend months working on a feature only to realize at the end that the problem they were trying to solve was different than they had initially anticipated.

The Pros

• A strong emphasis is put on building out requirements documentation
• New team members can easily familiarize themselves with the project details
• Phases are clearly defined
• The end user knows what to expect

The Cons

• If initial requirements are off, projects are likely to fail
• Development process can become resistant to change
• Everything gets tested at the end of the project, meaning errors can have a significant impact

The biggest, and most important con for the waterfall model is that the initial plan doesn’t account for the end user (your) evolving needs. It’s simply less flexible and adaptive.

Fun waterfall fact – The first formal diagram of the waterfall method was introduced in 1970 by Winston W. Royce. With the diagram, he included major flaws that he described as “risky and inviting failure”. He also included 5 steps to eliminate development risks. However, only the diagram went mainstream, the additional 5 steps did not.

The Agile methodology

The Agile methodology is a little younger than the waterfall model having been introduced in the early 90’s. With this model, a stronger emphasis is placed on optimizing development time and creating working software (or features) in as little time as possible, getting feedback, and making incremental improvements with regular frequency.

The Manifesto for Agile Software Development breaks it down like this:

• Individuals and interactions over processes and tools – If the process or tools are driving development, the team is less responsive to change and less likely to meet customer needs. When people are driving development, communication is fluid and changes can be dealt with immediately.
• Working software over comprehensive documentation – Agile doesn’t eliminate documentation altogether, but it does streamline it. Requirements are documented as ‘user stories’ that have the information required to start developing new functionality.
• Customer collaboration over contract negotiation – The waterfall method excludes customers during the actual development process, whereas the Agile model includes the customer throughout the process and is more likely to meet customer needs because of it.
• Respond to change over following a plan – For the waterfall model, change is basically an expense. With the Agile methodology, change is an opportunity to improve a product or feature and provide additional value to the end user. 

The Pros

• The ability to ship iterations and make continuous improvements
• It allows for customer requirement changes
• Easier to add features, faster
• Frequent testing helps catch errors throughout the development
• Customers can give feedback to ensure they get what they need

The Cons

• With no definitive plan, the end result can often be much different than initially expected
• Unsuitable for processes that require formal planning and complex decision-making, like construction

Waterfall or Agile, which is better?

While there are certainly still development teams that leverage the Waterfall model, the numbers from the Standish Group Chaos study paint a clear picture. According to their 2018 study:

• Agile projects are 60% more likely to be successful than Waterfall projects
• Waterfall projects are almost three times more likely to fail

Aside from success metrics, one of the biggest differences between waterfall and agile is the ability to ship iterations. For example, with the Waterfall model, you’ll wait 6 months for a feature to release. On the flip side, with agile you get an initial release and then iterative improvements (new features/feature enhancements) at frequent intervals until it’s on par with the waterfall delivery.

Think of it this way – Let’s say that you are owed $20. Would you rather get $20 4 months from now or $5/month for the next 4 months? The difference here is incremental value. 

Why Bridgit chooses Agile

“By choosing to go agile, we give our customers a voice during the execution of new features…” – Andrew Lockwood, VP of Engineering & Product

1. Incremental value delivery

The Agile methodology allows us to execute an initial minimal viable product (MVP) and get it in the hands of our customers, fast. This allows us to maximize our learning of what is actually of value to our customers, iterate on those learnings, and continue to add value to our product and features.

2. The ability to rapidly shift priorities and respond to customer demand

Choosing the Agile methodology allows us to put our customers first. By using an iterative process, we’re better able to adapt to the changing needs of the construction industry.

3. A people-first approach to software development

Like construction, our success is rooted in our teams. Working in an agile fashion empowers our development teams to make critical decisions on their own and in the moment which drives a continuous flow of high-quality, well-received customer-centric features and enhancements in Bridgit Bench. 

Agile in practice – The People Gantt

Release 1. The MVP

We started by releasing our People Gantt, helping our customers visualize their entire team’s individual utilization rates in the coming months and years. The initial response was positive, but we received feedback that our customers wanted to be able to narrow the focus of the People Gantt. They needed filters.

Release 2. People filters

Getting feedback about the need for filters allowed us to shuffle our priorities to ensure our end users had what they needed to do their job effectively. So, we added the ability to apply powerful filters. Again, the feedback was positive, but now that our customers could narrow the focus of the Gantt, they wanted to share that information across the organization. They needed reports.

Release 3. People Gantt Reports

Now we have a People Gantt that needs to be shared, so we shuffle priorities again and give our customers the ability to export highly visual PDF reports. The focus of the feedback now shifted to projects. While the People Gantt displayed how their team members were being utilized, it didn’t show them which projects they were allocated to. Enter People Gantt customizations.

Release 4. People Gantt custom settings

Now we’re really ramping up the incremental value. Instead of just adding project allocation bars to the People Gantt we take it one step further and give our customers the ability to completely customize the data being shown in the report. Display project allocations, utilization, even employee pictures and titles can be hidden to display more information.

The end result is a People Gantt that our customers love to use, but we were able to provide incremental value to our customers right from the release of our MVP. That’s the value of the Agile methodology. It allows us to put our customers first and ensures we’re actually solving their problems and continuously making their lives easier with every release. For more information about Bridgit Bench and resource planning, visit our blog. To learn more about construction workforce intelligence, check out our guide.