There are already articles about different development approaches, such as Waterfall, Scrum, and Kanban in our blog. Each methodology has weak and strong sides that you should keep in mind before making your decision. But you should also remember that different approaches could be used side by side in one project. To understand how these different methodologies can be combined, we’ll take a look at the most valuable differences between them. Then, we’ll check how different approaches were applied in a real project.
Waterfall Model. Main Features
Let’s start with a brief review of the Waterfall Model. This approach differs from the other two we are talking about. Unlike Scrum and Kanban, Waterfall is not an iterative process. It means that every step runs only once. The project is implemented step by step, according to initially defined sequencing. Here’s the typical sequence of steps true for the cascade model:
1. Requirement analysis
2. Design
3. Development
4. Testing
5. Maintenance
These steps may differ from project to project, but the overall idea stays the same.
Like any other model, Waterfall has its weak sides. For example, if there will be an error at the very first phase of development, you’ll be able to find it only when you start the Development or Testing phase. Thus, it’s recommended to use this approach only in one case: if all requirements are clear, and there are no doubts that there will be any changes.
Scrum and Kanban. Main Differences
Unlike Waterfall, Kanban and Scrum have much in common:
– Both refer to Lean and Agile software development principles
– Scrum and Kanban are PULL systems
– Both models main priorities are the minimization of documentation used during the project and communication among the team members at each step. As a result, workflow visualization is one of the central concepts of these two software development models
– WIP (Work In Progress) minimization is a must
– Frequent product release
Let’s have a look at the main differences between Kanban and Scrum.
WIP Minimization Approaches
One of the most significant concepts for both Scrum and Kanban is the minimization of active tasks. But there are different approaches that allow you to minimize WIP.
Here’s an example of how you can visualize the development process:
According to Kanban, the overall number of active tasks should be limited for every working phase. It’s pretty hard to choose the ideal number of tasks right after you get started with your project. But after you finish a couple of iterations, you’ll understand what value works better for you.
Scrum doesn’t limit you with the number of active tasks. All that matters is the number of tasks that will be developed during the sprint. This number should be chosen according to the term that will be spent on a particular task. This term is measured in story points. After a couple of finished iterations, the development team knows its average working speed, and it’s much easier to determine the amount of work that could be done during the next sprint.
Differences Between the Scum Board and Kanban Board
At the very first steps of development, you should create a Product Backlog. It’s a list that contains tasks your team will work on during the development process. In the case of both methodologies, during the workflow visualization process, the tasks are moved from the product backlog to the board. What differs is the way you move your tasks from phase to phase.
In the case of Scrum, every iteration is called sprint. Before every sprint, you should create a sprint backlog based on the product backlog. You should put the tasks that will be finished during the next sprint in this list. Thus, all the tasks that are part of a particular development phase are part of the sprint backlog. The product owner can watch the sprint backlog, but he can’t change the sequence of tasks it consists of. All that he can change is the product backlog. The result of every sprint is a working product. After the retrospective and product demonstration are done, the product owner can decide if this product worth of release or not. These final steps are not part of the backlog and not displayed on the board.
Here are the differences you may face if you work with a Kanban board. After the sprint is finished, the Scrum board is cleared of tasks. Kanban board, in its turn, contains all the tasks that the whole development process consists of. That’s why we can say that the Kanban board remains unchanged during the working process. The other important thing. The very last stages of the project, such as product installation are usually represented on the Kanban board.
Using Different Approaches. Real Project Use Case
Project: Online Data Storage Application Of High Performance
The developed project represents a web-based business application that gives you access to the source of data and statistics on developed and developing markets. It was designed to process millions of data series from different periods and countries. At the same time, one of the requirements was to make the app responsive enough to make this data available for over 500,000 users at a time. It is created for everyone who needs to do fast research and data analysis.
Let’s take a look at how different methodologies can be used at various stages according to changing circumstances.
It can be hard to follow the chosen methodology strictly during the development process. There are rare exclusions that can be caused by the situation when one of the customer’s requirements is to follow the particular development methodology.
In other cases, approaches combination is preferable.
Usually, developers use Scrum during the so-called “calm” stage of the project, when there are no expected releases or presentations.
When the development process is close to its final stages (e.g., a presentation or release), developers gradually change the currently used approach to Kanban. Here’s how it looks like in practice. The team has a reference point – release date, for example. Starting from the particular moment, team members begin to work on the tasks they receive from a customer in the form of a prioritized list daily.
It’s better to use Waterfall if you want to implement some functionality that is big enough, valuable enough, and, what’s more important, separated from the overall project. For example, such an approach was used during the work on the Excel add-in for the mentioned data storage app. The most important in this case is to be sure that all requirements are clear. If so, the team can document all requirements and start to develop.
Conclusions
To manage the software development process in the most successful way, you should be able to switch from one methodology to another during the working process. Usually, it’s not enough to choose Scrum, Kanban, or any other model and follow it to achieve your goals. In the case of a big project that requires a lot of time to finish it, circumstances can change unpredictably. That’s why, besides a clear understanding of different features of particular development methodologies, it’s crucial to understand the main differences between various approaches. If you face some unsolvable troubles, such skills can help you find the appropriate solution. You can spend your time searching for a solution that might or might not exist in terms of your current methodology. Or you can change the approach that you use to another one that was initially designed to solve the problems you faced.