Choosing a Software Development Model: Predictability vs. Velocity


Choosing a Software Development Model: Predictability vs. Velocity

Deciding on a software development model is one of the most critical and challenging decisions a company makes. New projects have such potential, and many project managers fear to squander that potential by choosing the wrong model to develop the software.

We're going to cover how to choose the right software model for your project. But first, let’s review what a software development model is and what the options are.

Software Development Model Options

A software development model is the set of processes and procedures that govern the development of a software project. It’s your “modus operandi,” so to speak.

All software models balance two factors: predictability and velocity. You can precisely know what you’re building, but build it slower, or build fast and change as you go. There is no right answer, only the right solution for the specific project.

Think of a puzzle. A predictable development model is carefully looking at the picture on the front of the box before putting it together. If you run into a rough spot, you recheck it to help guide you along the way.

A model favoring velocity tears open the box, throws it away, and starts putting the pieces together, not knowing what the completed puzzle is. You try different combinations until you find something that fits. The picture is built gradually over time. And no one knows what form it will take when it’s done.

The ever-present waterfall model is an example of a predictable development model. The project progresses through clear stages, with each step ending before the next begins. You decide all requirements before development begins. The developers build based on a solid plan that doesn’t change quickly. Then testing happens all at once, followed by the release of the software.

Waterfall can include testing loops and iterations. A large project can be broken into smaller pieces that each follow the waterfall process, for example. Still, waterfall is generally prescriptive up front, not starting until a large amount of information is known about the project.

Agile methods such as Scrum or Kanban exemplify the velocity side of the equation. They focus on iterating quickly and working closely with product owners to move toward the finished product. You don’t know what the result will look like, only that it will satisfy the needs of the business as defined by the product owner.

Pros and Cons of Predictability and Velocity

Every choice has consequences. You can be prepared for those consequences when you know what to expect ahead of time and how to handle them.

The predictable software development model allows the project team to see the entire picture of the end product before beginning development. You’ll always have the image on the front of the puzzle box to tell you where the pieces fit.

You’ll be sacrificing velocity since it will take longer to build a complete picture of the project upfront. However, you’ll also be able to fully optimize the design before building, making the building phase more straightforward.

An approach based on velocity, such as an Agile methodology, gives you the ability to see a working piece of software right away. You know the business outcome you’re trying to achieve, but the team decides how to make it.

Collaboration is king with velocity-based models. If the product owner and development team don’t work together closely, the principle of emergence states that they’ll likely end up with a ball of string that is more complex than an upfront design would have been. The shorter planning horizon exposes you to a risk of rework.

Steadily building new granular services without strong architectural oversight and design can lead to messy systems. They become difficult to manage because of emergent properties and interdependencies, and they become more expensive and less flexible than a single application would be. Segment wrote a brilliant article about why they went back to a monolithic application from microservices.

Velocity-based approaches lead to more uncertainty. You won’t know what your building until you build it. You’ll bring it to market faster, but you’ll always be tweaking and changing it. While some preliminary architectural design is necessary in all models, velocity-based models tend to favor rapid progress and embrace change.

A slower, predictable approach takes longer but has less chance for scope creep and a “bolted-on” piece of software that causes significant headaches down the line.

There isn’t a right way to build software. Once you’re aware of the tradeoffs between predictability and velocity, you can decide which is best for you. Let’s dive into how to choose between the two models in your project.

The Software Development Model Decision Tree

We don’t prefer either model. The needs of the project will decide the most beneficial way to build the software.

The first factor to consider is the risk tolerance of the software. The company’s risk tolerance comes into play, but even within one company, different pieces of software carry more risk if they malfunction.

The core software application that manages day trading for a bank has to work according to precise specifications and according to applicable laws and regulations. A predictable approach works well to mitigate the risk of such an application by allowing the development team to optimize the application design while ensuring compliance.

A medical device is another example. If a malfunction could cause a life-threatening situation, the predictable approach will ensure proper levels of scrutiny and testing before the machines are made available. This “cost of error” should be considered when deciding your development model.

Small business applications and services that often front more complex pieces of software are better choices for the velocity model. The business should build the service well, but a malfunction doesn’t cause a massive financial impact on the company. A focus on velocity makes sense in this scenario so the team can iterate and gather feedback to create a satisfying user experience.

The second factor in choosing a development model is the budget of the project. How much is the company willing to spend to build the software? The predictable model tends to be more expensive than one that emphasizes speed. It is more challenging to create an expanded breakdown and full picture of the project ahead of time. The extra effort and cost mean that a predictable model requires deeper pockets.

In the short term, velocity-based models will save you money. You’ll build in small increments and use feedback from users to iterate and improve. Every sprint ends with usable software, so if money is tight, you’ll still have software that provides value, even if it doesn’t have all of the bells and whistles.

I said that velocity-based models save money in the short term for a reason. Because of the nebulous nature of velocity-based projects, they can go on indefinitely. A poor design increases the risk of rework and may cause the team to re-architect and rebuild the software down the line. These events could end up making the project more expensive in the long run when compared to predictable models. There is a lower cost per unit of value, but there is a higher cost spread over years of development.

The budget and risk tolerance work together to help decide on a software development model. When you pay for a software project is called a budget. When you pay your insurance company, you name it a premium. These two things are the same. You’ll pay a premium for predictable models because you’re insuring against future risk (and offloading that risk to your software development consultant).

On the other hand, velocity-based models produce a faster result and can be cheaper in the short-term. However, you’ll be taking on a lot of the risk as a collaboration between the client and consultant is the linchpin. Communication breakdowns lead to software breakdowns.

The third factor in choosing a development model is time. How quickly does a working piece of software need to be released? There may be market forces or other factors that drive you toward delivering a piece of software as quickly as possible.

The velocity model is the best choice when you need to beat a competitor to market. Apple has built an empire from delivering first to the market and then improving their devices over time. Agile models thrive when you can provide the first version, gather feedback, and then improve. It allows you to build a solid customer base and gain the first mover’s advantage.

When time isn’t a factor, a more predictable model will help to deliver a complete piece of software. And you can have checkpoints along the way to help ensure you’re on the right path. When we use a predictable model, we use the incremental build model, which allows for functional prototyping during the process. You can put to rest nightmares of waiting a year to see a piece of software that doesn’t do what you want it to do.

The three factors are risk tolerance, budget, and time. All three elements must be considered carefully before deciding on a development model. Let’s look at what models our clients in various industries choose.

No Matter What Model You Choose, You Can Succeed

Both predictable and speedy software development models can deliver valuable software. The tech industry and corporate worlds tend to latch on to the latest trend and try to make every project fit into a mold, whether it’s a proper fit or not.

We don’t believe in placing square pegs in round holes. Software development isn’t about the “right” or “wrong” way of completing a project. There is only the right way for the project in question.

On your next project, try to weigh your risk tolerance for the software, the budget constraints, and the time-to-market requirements carefully before choosing a model. If you need some help, contact us, and we’ll be glad to help you decide which model fits your requirements.

February 3, 2020

Explore More Resources:

What our customers say about us
Blaine Bunting (CEO, Atlantic Firearms)
Eric Fulkert (CEO, Campus Suite)
Todd Surber (Founder & CEO, PIXRIT)
Vince Hughes (Owner, Steel Estimating Solutions)
Bill Fahy (Owner, FDI Creative Services)
Ricardo Casas (CEO, Fahrenheit Marketing)
Rudy Milkovic (Executive Director & Founder, Velikom Interational)
Cory Kowal (VP of Products, THG Energy Solutions)
Bobby Burkholder (COO, Luchini & Mertz Land Surveying Co)


Sign a mutual NDA before a conversation.

When to sign an NDA?

Submit loading...

Was this page helpful?