The Software Development Life Cycle (SDLC) has been a mainstay in software development for decades, but choosing the wrong process can have disastrous effects on the productivity of your team. You can use SDLC for anything from software to hardware to even making cars. For purposes of this article, I'll be focusing on its use for software development. There are several flavors of SDLC, so I'll cover the most common ones here to give a good overview of what will work best for your project.
Waterfall Model 🌊
This is one of the oldest and most well known examples of SDLC. It begins with a phase for requirement gathering, followed by a design phase, then an implementation phase, followed by a testing phase, and finally a deployment/support phase. It gets the name waterfall due to the way the ideas come from the business stakeholders and eventually flow through the phases to make their way down to the workers who ultimately create and support the application.
Time spent early in the software production cycle can reduce costs at later stages. For example, a problem found in the early stages (such as requirements specification) is cheaper to fix than the same bug found later on in the process (by a factor of 50 to 200).
It generally has the reputation of being a reliable, albeit slow process, requiring project managers to create a communication channel between the stakeholders and the programmers & designers making the app. That being said, finding problems early on saves a tremendous amount of effort. Let's be honest, if you aren't doing some analysis before assigning tasks you're racing towards oblivion.
Kanban Method 📝
The Kanban Model is a popular choice for lean startups. It was based on systems created by Japanese car manufacturers. Kanban is far more minimal in its approach to phases compared to Waterfall, allowing teams to create their own combinations. Common phase choices include 'TODO', 'In Progress', 'QA', 'Done', and 'Blocked'.
Example usage of a Kanban Board
The Kanban Board is the main element of Kanban. Tasks can be written onto a note and a team member can be assigned the task. The visualization of Kanban helps teams foster a better understanding of the overall progress and lets managers easily get more insight into the work being done. And hey, it feels great to move your cards into the Done column! If a physical board isn't your style, there are some popular digital options out there such as Trello and Jira. 
Scrum Model ♻️️
Scrum is a newer contender but has seen tremendous adoption as the go-to for people looking to adopt an agile software development process. It adds quite a few components over other methods in an effort to create more robust feedback loops.
The Sprint 🏃
A critical component of scrum is the sprint. Sprints are time-boxed activities. Generally these are 1 to 4 week cycles. I've personally used 2 weeks sprints to some success.
Sprints usually start with the stakeholders and the project manager or scrum master meeting to discuss which items in the backlog are priority and generally how much they believe the team can safely finish within the sprint. This estimate is usually assisted with the velocity metric. Next, the team will have a sprint kickoff meeting where they meet and go over the sprint backlog. Everybody decides which issues they will tackle to establish ownership and buy-in for completing each task.
As work progresses from sprint backlog through to a completed state, daily scrum stand-ups are performed to increase communication and discover any potential issues early. Finding issues before they are a problem is the key to ensuring a successful sprint.
Scrum Standup Meetings
Standup meetings are typically done daily and early in the morning. This is the time for people to quickly mention what they completed, what they are working on, and if they are blocked on any issue. If external blockers are mentioned, the scrum master or project manager will flag it and bring it up with the proper team to find a resolution.
How do they stack up?
While waterfall does have its place within very structured organizations, it is highly inappropriate for anybody who wants to create something quickly. If you are not in government or a large bank, then you'll want to steer clear of this one. I've noticed even in large banks here in Toronto, they will call themselves agile but really they are practising a hybrid of waterfall with daily scrums.
Kanban VS Scrum
These two make for a better comparison. Both are considered to be in the agile stack and rightly so.
Kanban is much more free-form without rigid phases and without time-boxed objectives. However, some people struggle to implement this properly without it melting into a chaotic mess. I personally prefer Kanban in the initial phases of a product, before the MVP. The nature of it allows for rapid prototyping and quick adjustments to be made without waiting to make the pivot at a set interval.
Scrum shines when you practise it properly and everyone gets used to the slight overhead created by its components. The sprint and daily scrums are a powerful weapon to open up your communication channels as well as keeping focused on very tangible goals. I find it works best when you have a working product and you can take it from one well defined state to another well defined (and ideally better) state.
I hope this article helps you determine which process to use. This is an important decision as it can help you and your team reduce the hurdles of communication and keep process to a minimum. If you want to quickly get something done, try Kanban. If you want to maximize iteration, Scrum is for you.
Thanks to Paul Krajewski for recommending this incredible YouTube overview of scrum.
We were not paid to endorse any products. Any products mentioned are purely based on our experiences. ↩︎