Many experts consider the traditional software development life cycle (SDLC) methodology harmful. But why is this? What are the disadvantages of using the SDLC instead of an agile methodology? This blog post will discuss these disadvantages and see why the software development life cycle might not be the best choice for your next project.
Free code review checklist and best practices
DownloadThe software development lifecycle, sometimes known as the SDLC, is perhaps the most frequent misconception about software development. You may find something like this if you Google the phrase: "according to ISO/IEC/IEEE 12207 typical Software Development Life Cycle, there are the following stages: Requirements, Design, Develop, Test, and Release"
You can also find two images of the Waterfall model SDLC, with the stages in one row, and the Agile software development life cycle, where the process repeats in a loop.
Isn't it true that software development teams should deliver working software this way? But it isn't.
The Agile SDLC model is not about steps; the Agile software development life cycle is about delivering working software in continuous flow. We should plan continuously, build continuously, and test continually from the very beginning. Agile workflow is not a line; there are no Agile phases; the processes are proceeding in parallel. Even ISO/IEC/IEEE 12207, primarily intended for public procurement, does not mention stages.
A staged process is a Waterfall model; a staged iterative process is not an Agile life cycle; it's a series of mini-Waterfalls. It is ancient, out of date, and does not function effectively.
Only 11% of Waterfall projects are deemed successful by CHAOS Report 2015. In stark contrast, Agile methodologies boast four times the success rate. In their work "Life Cycle Concept Considered Harmful," published in 1982, Daniel D. McCracken and Michael A. Jackson wrote: "An increasing awareness that systems requirements cannot ever be stated fully in advance, not even in principle, because the user doesn't know them in advance-not even in principle.
To assert otherwise is to ignore that the process of building software changes the user's perceptions of what is possible, increases their insights into the application's environment, and often changes that environment itself. We suggest an analogy with the Heisenberg Uncertainty Principle: any system development activity inevitably changes the environment, out of which the need for the system arose. Therefore, system development methodology must consider that the user, and their needs and environment, change during the process.
Today is 2022. Imagine the expense of software delivery failures over 40 years! Please don't discuss the requirements before you start working on them. Don't have an "I need to think everything over" attitude during the concept phase. Instead, begin with an iterative approach, choose small but essential key requirements, and work your way up. It is the only method to save time and budget and ensure your customer satisfaction.
The SDLC misconception affects not just the requirements process. The second victim of this software development process being implemented incorrectly is QA. Testing isn't an agile life cycle phase following development.
Imagine a chef with a runny nose who cooks with his eyes shut. And a waiter that smells and tastes the dish before bringing it to the client. That's how a test on the end looks. So what happens if the meal is terrible? Typically, we term it a "missed deadline."
Imagine a tester with a $70,000 annual salary who spends one day manually checking to see if a developer with a $70,000 yearly wage failed his assignment. If the task is unsuccessful, the developer will work for one week to repair it. It will set you back around $2,000 and a week of effort to fix it. That is the cost of testing at the end.
In "The Mythical Man-Month," Fred Brooks suggests that development accounts for 1/6 of the entire project time, with testing and fixing accounting for another 1/2. It was 1973, and they utilized Waterfall and the "test after" method.
Also, why should a tester who just clicks the mouse all day be paid the same as a developer? The testers should not spend all of their time clicking. It's ineffective and painful, in addition to being unethical. What if QA creates a list of predetermined criteria for their agile team that must be satisfied before a task can be confirmed as ready? What if these criteria are carried out automatically during the checks?
In this situation, testers operate to prevent bugs rather than find them. They don't perform the final test; everyone in agile teams does it continuously. QA gains time by eliminating rework efforts and saving cross-functional teams personnel hours. The system has living documentation that is updated as the agile projects progress. It is a continuous self-checking documentation development process, ensuring it functions as intended.
What's the cherry on top? First, there is no "we don't have time to automate tests" problem. The tests are already automated to assess job readiness. A company should not constantly choose between lowering the time and cost of manual testing and adding new features. The quality is built-in as a part of the Agile process, which is impossible if testing occurs after the software development team works.
There are many names for these techniques - TDD, BDD, Acceptance Testing, and Specification by Example, but they all "breach" the typical understanding of software development life cycle models. Testing is not a phase after agile development. Check out this article to read about Agile test automation.
Why do companies continue to use the traditional SDLC approach when we've known for almost half a century that it's incorrect? First, of course, it's due to budget constraints. How much money is required to create whatever they want?
What is the most straightforward approach for a software development firm's salesperson to earn the bonus and close the sale? That's correct. State the final product price. The consequences will not occur immediately but instead in the future.
But how can we know the price if we don't know, even, in theory, all the features? Because the incorrect project price becomes the primary contract negotiation factor, the sales process devolves into guessing, if not lying, rivalry. This is certainly not part of agile software development methods and explains why only 11% of Waterfall projects succeed.
Another approach to budget agile software development teams is to look at it from a different perspective. Every executive knows a company's MRR and the proportion of that revenue that may be spent on certain things. Typically, agile software development is not a one-time expenditure; it's a series of monthly payments. We live in a world where such a model reigns, and we budget office costs without knowing how many people will visit it and pay for internet usage without knowing how many gigabytes will be downloaded. As a result, we budget for agile development without a clear picture of what we'll make.
Businesses are well-versed in their monthly financial constraints; agile software development teams, on the other hand, charge by the hour. So choose those who enjoy working together and have industry expertise based on your budget.
What if it's the incorrect choice? Delivery is also a continuous agile process, so if the working software is delivered in tiny but valuable pieces every two to four weeks, the company will be aware of the wrong choice as soon as possible. The risk of receiving a smaller value than anticipated is nothing compared to the danger of failing entirely in completing the project after months of development due to the wrong project planning.
Do upfront estimates help to minimize the risks of software development projects? Do they guarantee that the final version of the product will be finished on time and within the budget?
According to Steve McConnell's book "Software Estimation: Demystifying the Black Art," which is perhaps a bible of estimation, the uncertainty on the stage after requirements are finished is 2.25 times. So it is the lowest level of uncertainty - when the estimate is made correctly, and project management can make decisions and manage scope and resources.
In reality, when a budget is established, there are generally no specified requirements, and the project manager has little control over the scope and can't hire top developers. In addition, of course, the scope will vary due to changes in your business needs. So what is the worth of such an estimate?
That is why, in most cases, Waterfall projects fail. The company that can effectively lie to the customer wins the contract. Even if you're telling the truth and it's all very real, no one would take "from $10k to $500k" seriously.
Another issue is an underestimation. Senior developers are more aware of pitfalls and consider additional factors than less experienced individuals. Junior employees overlook many routine tasks that should be completed.
Consider a client who has received ten bids from prospective vendors in the range of $10k to $500k. What would you do if you were in the shoes of any reasonable person? Naturally, you'd pick the one with the "reasonable price." But unfortunately, it also implies less skilled developers with worse estimating abilities.
But what if a developer gives an estimate and commits to a fixed-price project? Is it possible for consumers to avoid any financial setbacks as a result of an incorrect guess? Unfortunately, that is not the case. If the project isn't completed on time, there's no way to get it done ahead of schedule. The deadline will be missed. Being late has the potential to result in far more significant losses than planned expenditures. Not to mention, the Death March needs a sacrifice, and it is quality.
What is the remedy? What can really lower your risks? A recurring monthly budget, small iterations, rapid feedback, and no fear of modifying scope at any moment.
How do I deliver my product by the desired date? How can I make sure I don't miss the deadline? It's also possible that the date cannot be changed for legitimate business reasons. Exhibitions, conferences, and holidays like Black Friday are examples of when it may not be feasible to move the date. Some legal changes necessitate a building deadline.
Yes, we don't know how long it will take because we can't define the scope ahead of time. We don't know how long it will take, but we need working software to date. Does it appear to be a mission impossible? Shouldn't we go back to "traditional SDLC," even if it isn't effective?
Unfortunately, the illusion of control will not deliver actual control. What if the plan goes wrong in some way? What would happen if the plan is incorrect in any manner? It's more than likely to be incorrect. The software development team will have to work overtime to complete the project, which will be stressful and time-consuming. Code and project architecture chaos would result from exhaustion while slowing down is unavoidable. It's a Death March. As Robert C. Martin puts it, the only way to go fast is to go well.
Remove the waste instead. Create something small that can fulfill the most basic requirements. Do it as soon as possible, iterate, improve, and add new capabilities as often as possible before the deadline. Then, at each point in time, have fully functional software.
Do you need to show off something at an exhibition? A simple UI prototype will likely perform worse than a complex web application and perhaps attract fewer consumers, but it will work. A rich web application that is not yet finished will not. Even for new legal requirements are required, there is a chance to mitigate risks because not every consequence is the same. Work your way up from the worst-case scenario and then iterate to cover the rest.
You have no risk of failure when ready-to-use software is completed well ahead of the deadline. All additional features and enhancements will help you succeed and strengthen the competitive environment. In addition, you can skip over any unfinished elements on the date because most essential components of the software have already been created.
As any project manager knows, the software development life cycle (SDLC) can be a complex and time-consuming process. Managing development teams, coordinating different project stages, project planning, and ensuring quality assurance can all be daunting tasks.
However, there are a number of ways to overcome problems with the SDLC process and ensure a successful outcome. One way is to establish a recurring monthly budget. This will allow you to track costs and ensure they stay within the project's scope. Iterative development can also help improve communication and coordination between agile software development team members. Rapid customer feedback can also be used to identify and solve problems quickly. Finally, don't be afraid to modify the project scope at any moment. By being flexible and adaptable and adopting agile methodology, you can overcome any obstacle that comes your way.
This article may capture your attention if you are searching for a Shopify expert who employs Agile SDLC.
VT Labs does agile development for Shopify stores, to move faster than competitors. You get store improvements every week and can change priorities anytime.
