Jory is a writer, content strategist and award-winning editor of the Unsplash Book. He contributes to Inc., Fast Company, Quartz, and more.
October 02, 2019 · 12 min read
There are lots of things in life that are better with a little spontaneityrelationships, weekend plans, tattoos. But software development isnt one of them. Instead, as Benjamin Franklin so famously put it:
Every great piece of software starts with a plan and a clear process in place. Luckily, there are numerous software development processes you can choose from when youre starting your next project. But which software development process is right for you?
In this guide, well go over the basics of your software development lifecycle, why its so important to understand, and then cover the pros and cons of the five best software development processes
The SDLC: What is the software development lifecycle and why is it so important to have one?
Whether you plan it or not, every piece of software goes through a similar path from idea to launch day. Collectively, the steps of this path are called the software development lifecycle (or SDLC for short). The SDLC is the sequence of steps that take place during the development of a piece of software.
Traditionally, each step creates an outputwhether an idea, document, diagram, or piece of working softwarewhich is then used as the input for the next step. And so on until you hit your goal.
That being said, software is never really finished. Even the release of your first version can be seen as just another step in the lifecycle of your software.
The importance of having a clear process and knowing your development steps cant be understated.
Even though you can launch software without a clear process in place doesnt mean you should. Thanks to years of testing, iteration, and development, modern software development processes make building new tools cheaper, more efficient, and less stressful.
But maybe even more than that, using a formalized SDLC has a number of other benefits:
- Creates a common vocabulary for each step along the way
- Defines communication channels and expectations between developers and project stakeholders
- Sets clear roles and responsibilities for your entire team (developers, designers, project managers, etc...)
- Provides an agreed-upon definition of done for each step to stop scope creep and help keep the project moving
- Formalizes how to handle bugs, feature requests, and updates
On the other hand, not having a software development plan in place means longer timeframes, subpar quality, or even outright failure. Even worse, your developers wont know what to make. While your project managers will have no clue how much progress has been made and whether youre on budget or even on track to complete it!
Deciding whether to have a formal software development process is like asking if youd rather stumble around in the blazing desert heat hoping youll run into an Oasis, or have a map that takes you straight there.
I know which option Id choose. So lets start by understanding the core building blocks of the SDLC and then look at how to optimize them by choosing the right software development process for your team.
The 7 stages of the SDLC
If youre a project manager, youre probably already familiar with the different steps in the SDLC. As the shepherd for a digital project, you have to think about everything from requirements to stakeholder communication, development, and ongoing maintenance.
These steps are all pretty much the same across any software development process you use. However, as well go into later, the order and sequence they occur in can change depending on your needs, goals, and project and team size (for example, some steps might be combined, duplicated, or run in parallel).
1. Analysis and Planning
Once a customer or stakeholder has requested a project, the first step of the SDLC is planning. This usually means looking into:
- Alignment: How does this project connect to your companys larger mission and goals?
- Resource availability and allocation: Do you have the people and tools you need to take this on? Or do you need to hire a new development team?
- Project scheduling: How does this project fit within your companys goals and other tasks?
- Cost estimation: How much is it going to cost?
The planning phase ensures youre starting off on the right foot. So try to make sure you include all of the departments that are going to be impacted by this project, including project managers, developers, operations, security, and key stakeholders.
At the end of the planning phase, you should have enough information to put together a high-level scope of work (SOW)a plan that details whats being built, why, and how you see it coming together.
The next step is to understand the technical requirements of this project. Every piece of softwarewhether its an app, website redesign, or new featureneeds to solve a customer problem.
As you move on from the planning phase and continue to fill out the SOW, ask questions about the specifics around this project, such as:
- What problem does this solve?
- Whos going to use it and why?
- What sort of data input/output is needed?
- Will you need to integrate with other tools or APIs?
- How will you handle security/privacy?
Once your development team gets the answers to these questions, they can start to scope out technical requirements, testing terms, and decide on a technology stack. This phase is also where you might start sprint planning (if youre using an Agile software development process) or break down large tasks into more actionable steps.
3. Design and Prototyping
With the requirements in place, its time to start designing what this software will look like and how it will function. Were not talking about aesthetics here, but functionality and flow. As Steve Jobs famously said:
Depending on the software development process youre following, this phase of the SDLC might mean you create simple wireframes to show how interactions will work in the software, or make more full-fledged prototypes using a tool like Marvel or InVision to test with users. Alternatively, you might decide you need more user feedback and do a design sprint to quickly get a feature or idea in front of your users.
However you choose to tackle it, this stage helps your team and your clientwhether a customer or stakeholdervalidate ideas and get valuable feedback before you commit your ideas to code.
4. Software Development
With everyone onboard with the softwares proposed functionality and design, its time to build it according to the requirements and SOW.
This phase is obviously the hardest and potentially riskiest stage of the SDLC (and each of the software development processes well discuss below handle it differently.) However, whether youre working in Agile sprints, building out an MVP, or using the more traditional waterfall method, the goal here is to stick to the SOW, avoid scope creep, and build clean, efficient software.
As your team is developing the software, youll most likely be simultaneously testing, tracking, and fixing bugs. However, once the features are complete and the product is deemed ready to go, youll need to do another round of more in-depth testing. This could mean releasing the product to a small group of beta testers or using UX tools to track how users interact with it.
While testing could be another long stage of the SDLC, its important to make sure youre not shipping buggy software to real customers. As we wrote in our guide to bug tracking tools and workflows, bugs can kill your reputation, make you lose revenue, and, worst of all, take up hours of development time that couldve been put towards building new features.
With the heavy lifting (and coding) out of the way, its time to launch your software to all of your users. What were talking about here is pushing your code into production. Not coming up with and implementing a go-to-market strategy (thats more up to your sales and marketing teams).
In most companies, this step should be pretty much automated using a continuous deployment model or Application Release Automation (ARA) tool.
7. Maintenance and Updates
The SDLC isnt over once your software is in the wild. Its a lifecycle, remember? The ending of one phase is just the beginning of another, and that goes for post-launch as well.
Requirements and customer needs are always evolving. And as people begin to use your software, theyll undoubtedly find bugs, request new features, and ask for more or different functionality. (Not to mention the basic upkeep and maintenance of your application or software to ensure uptime and customer satisfaction.)
All of these requests need to flow back into your product backlog of task list so they can be prioritized and become part of your product roadmap.
The 5 best Software Development Processes (and how to pick the right one for you)
While the SDLC we outlined above might seem like a step-by-step plan for building software, its really more of a guideline.
Yes, you need to check each box to ensure youre shipping and maintaining great software. But how you check them, when, and in what order is up to you. Over the years, a number of different software development processes have been formalized to tackle more and more complex projects. But which one is right for you?
Ultimately, which process you use will come down to your goals, the size of the project and your team, and other factors. To help you decide, here are 5 of the best software development processes with pros and cons for each.
What it is:
The Waterfall software development process (also known as the linear sequential model or Classic lifecycle model) is one of the oldest and most traditional models for building software. In its most basic form, you can think of the Waterfall method as following each step of the SDLC in sequenceyou have to finish each one sequentially before moving on. However, in most practical applications the phases overlap slightly, with feedback and information being passed between them.
Some people also like to call this a plan-driven process as in order to complete a project, you first need to know everything that needs to be done and in what order. Hence the name Waterfall as each section flows into the next one.
- System and software design
Who its for: Teams with rigid structures and documentation needs.
Due to its rigid structure and big up-front planning time, the Waterfall software development process works best when your goals, requirements, and technology stack are unlikely to radically change during the development process (such as during shorter one-off projects).
In more practical terms, the Waterfall process is best suited for larger organizations (like government agencies) that require sign-offs and documentation on all requirements and scope before a project starts.
Who its not for:
If youre testing a new product, need user feedback mid-stream, or want to be more dynamic in your development process, following the Waterfall development process probably isnt right for you.
While straightforward, this processs biggest drawback is that it lacks flexibility. You wont be creating and testing MVPs or prototypes and changing your mind along the way. And because of this, unless your scope is tightly written, you might end up committing to the wrong path without knowing it until launch day.
2. Agile and Scrum
What it is:
The Agile software development process (and its most popular methodology, Scrum) opt for an iterative and dynamic approach to development.
As opposed to the Waterfall process strict, sequential flow, in Agile, cross-functional teams work in Sprints of 2 weeks to 2 months to build and release usable software to customers for feedback.
Agile is all about moving fast, releasing often, and responding to the real needs of your users, even if it goes against whats in your initial plan. This means you dont need a full list of requirements and a complete SOW before starting work. Instead, youre essentially moving in one direction with the understanding that youll change course along the way.
Theres a lot more to Agile than just this (which we cover in this Guide to implementing Agile and Scrum). However, heres a simple example of how it might look in practice. Lets say youre building a new feature for one of your products that could have X, Y, and Z features. Rather than spend months building everything, you would spend 2-4 weeks creating the bare minimum that is both useful and usable (in whats called an Agile Sprint) and then release it to your customers.
This allows tighter feedback loops throughout the software development process so you can adapt and react to real customer needs.
- Product Backlog
- Sprint backlog
- Sprint (Design & Develop)
- Release working software
- Feedback and validation (add to backlog)
- Plan next sprint
Who its for: Dynamic teams doing continuous updates to products.
Thanks to its dynamic and user-focused nature, Agile is the software development process favored by most startups and technology companies testing new products or doing continuous updates to long-standing ones.
As it becomes easier to do small releases and gather user feedback, Agile allows companies to move faster and test theories without risking their entire livelihood on a major release their users hate. Also, as testing takes place after each small iteration, its easier to track bugs or roll back to a previous product version if something more serious is broken.
Who its not for: Team's with extremely tight budgets and timelines.
On the flipside, Agiles dynamic nature means projects can easily go over their initial timeframe or budget, create conflicts with existing architecture, or get derailed by mismanagement. This means its not the best choice for risk-averse or resource-strapped teams.
Additionally, using Agile and Scrum takes dedication and a solid understanding of the underlying process to pull off properly. Which is why its important to have at least one dedicated Scrum master on your team to make sure sprints and milestones are being hit and the project doesnt stall out.
3. Incremental and Iterative
What it is:
The incremental and iterative software development processes are a middle-ground between the structure and upfront planning of the Waterfall process and the flexibility of Agile.
While both follow the idea of creating small bits of software and exposing them to users for feedback, they differ in what you create during each release.
In the Incremental software development process, each incremental increase of the product adds a simple form of a new function or feature. Think of it like coming up with an overall plan, building an MVP with only the core functionality, and then adding features based on feedback.
In the Iterative software development process, however, each version you release includes a version of all your planned features. Think of it like building a v0.1 with the most simple version of each feature and then upgrading it across the board in v0.2, v0.3, and so on.
- Increment Planning
- Repeat for each version
- Testing (Repeat these until youre ready to release)
Who its for: Teams with clear requirement who want more flexibility than the Waterfall method provides.
Both of these add a certain level of flexibility to your software development process without throwing an overall plan out the window, making them ideal for large projects with defined scopes (or teams with less risk tolerance).
With the incremental process, you get early feedback on your core feature, which can help you validate your business case right away. Whereas the iterative approach gives users an early look at what the full product could be so youre able to get better and more focused feedback.
In both cases, youre talking to users early on about what they actually want, which can save you tons of time, money, and headaches than if you waited until later in the development cycle.
Who its not for: Team's without a clear long-term technology plan.
Unfortunately, trying to add structure to a flexible approach has its own issues. Maybe your companys goals, procedures, or technologies change over time, making previous iterations useless or broken. Or perhaps your codebase gets messy and bloated due to adding functionality without looking for efficiencies.
Additionally, both of these models (and the iterative approach especially) require heavy planning and architecture-building early on. Meaning they arent ideal for smaller projects or teams who are still testing out use-cases and trying to find product-market fit.
Whats the difference between Incremental, Iterative, and Agile?
If you just read the last few sections, you might be curious about the difference between the incremental, iterative, and Agile software development processes. While they are pretty similar, there are a few key differences.
Each increment in the incremental approach builds a complete feature. While in iterative, youre building small portions of all features.
Agile, on the other hand, combines aspects of both approaches. In each Agile sprint, you build a small portion of each feature, one at a time, and then gradually add functionality and new features over time.
What it is:
The V-shaped software development process is a take on the classic Waterfall method that makes up for its biggest downfall: A lack of testing.
Rather than work sequentially through the development process and save all your testing for the end, each stage of the V-shaped process is followed by a strict validation and verification step where requirements are tested before moving on.
- High-level design
- Low-level design
- Unit testing
- Integration testing
- System testing
- Acceptance testing
Who its for: Teams working on smaller projects with a tight scope.
The V-shaped software development process is great if youve got a small project with relatively clear (and static) requirements and scope. Instead of running the risk of following a plan only to find issues at the very end, it provides ample opportunities to test along the way.
Who its not for: Teams who want more flexibility and early input from users.
Even the best-laid plans often go astray. And the downsides of this process are basically the inverse of its positive features.
First, theres a lack of control due to the fact that youre following a rigid structure and testing schedule. Without early input and feedback from your users, you still run the risk of building the wrong software for your business case. And finally, if youre building anything beyond a simple, small project, its nearly impossible to create a specific enough development plan beforehand.
What it is:
The Spiral software development process combines the V-shaped process focus on testing and risk assessment with the incremental nature of Iterative, Incremental, and Agile.
Once a plan is in place for a specific iteration or milestone, the next step is to do an in-depth risk analysis to identify errors or areas of excessive risk. For example, lets say as part of your plan you come up with a feature that hasnt been validated with customers. Rather than just add it to your current milestone, you might build out a prototype to test with users before moving into the full development phase. After each milestone has been completed, the scope expands further out (like a spiral) and you start with planning and another risk assessment.
- Risk Assessment
- Development and validation
- Evaluate results and plan next loop
Who its for: Risk-averse teams working on large projects.
Obviously, the core purpose of a process like this is to reduce risk. If youre working on a large or critical project that requires a high level of documentation and validation along the way, following a path like this might make sense. Its also beneficial if a customer isnt totally sure about the requirements and is expecting major edits during the products development.
Who its not for: Most people.
While fantastic in theory, the spiral software development process is rarely actually put into practice due to the time and costs associated with taking such a calculated approach. Instead, its mostly used as an example of how to think critically about an iterative approach to development.
Processes and plans are just guesses
When youre in the early stages of building out a new piece of software, it can feel like the paths laid out in front of you are endless. But instead of being overwhelmed, take a second and remember that every software development process and method comes down to four basic principles:
- Understand it: Know what you want to build and why.
- Build it: Design and develop working software.
- Test it: Give it to users to try and gather feedback.
- Evolve it: Use that feedback to make it better.
The same steps go for picking the development process thats right for you. Start by understanding the steps of the SDLC, then pick the process that feels right for you and your team, try it out, and gather feedback from your team. And remember, its a lifecycle. If you dont get it right the first time around, understand why it didnt work then pick a different process and start over.