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 (predictability), or build fast and change as you go (velocity). There is no right answer, only the right solution for the specific project.
What Is the Velocity Model?
To understand the velocity model, think of a puzzle. 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.
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 the Velocity model
There are plenty of pros to an approach based on velocity, such as an Agile methodology. First, it gives you the ability to see a working piece of software right away, and you’ll be able to bring your product to market more quickly. You know the business outcome you’re trying to achieve, but the team decides how to make it.
However, the primary drawback, or con, is that 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. So, if the product owner and development team don’t work together closely under the velocity approach, 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.
Planning with a Known Velocity
The velocity model is flexible, but that doesn’t mean it involves no planning whatsoever. When a development team has been working together consistently—and particularly when they have a few sprints from a current velocity-based project under their belts—they can measure with fairly high accuracy how long each slice of the project will take. For example, they may be able to say, “This team tends to deliver fifteen to twenty story points per two-week sprint.” (Note that it’s not total precision we’re looking for in these estimates; when you’re working with velocity, a ballpark is enough.)
Long-Term Planning with Velocity
“Story points per sprint” is a metric the development team can use to extrapolate into long-term planning, identifying roughly how much time larger segments of the project—or even the project as a whole—might require. For example, if they’re working at a rate of twenty story points per two-week sprint, then they know that, over the next six weeks, they’re likely to be able to complete about sixty points. With that in mind, they can work with the project owner, client, and any other key team member to identify the most important story points they should be focusing on during that six-week period.
What Is the Predictability Model?
To introduce the predictability model, let’s go back to that 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.
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.
Pros and Cons of the Predictability Model
On the pro side, 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, and you’ll be able to fully optimize the design before building, making the building phase more straightforward.
The biggest con on of this model is that you’ll be sacrificing velocity since it will take longer to build a complete picture of the project upfront.
The Software Development Model Decision Tree
So, you may ask, which model is better: predictability or velocity?
We don’t universally prefer either, because we know the needs of the project will decide the most beneficial way to build the software. There are three factors to consider when choosing which one is best for your project:
-
Risk Tolerance
The first factor to consider is the risk tolerance of the software. The company’s risk tolerance comes into play, but even within ne 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 organization 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.
-
Budget
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 on existing traits. 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.
-
Time
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.
Difference between Predictability and Velocity: A Recap
Velocity-based approaches lead to more uncertainty. You won’t know what you’re 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. On the other hand, a slower, more predictable approach takes longer to implement but comes with less chance for scope creep or costly “redos” and changes because it’s been fully designed and optimized in advance.
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 still aren’t sure, contact us, and we’ll be glad to help you decide which model fits your requirements.
