Scrum, Kanban and Waterfall: IT project management methods that get tasks done

To successfully accommodate all client requirements and simultaneously to be able not to exceed project budget, IT companies usually adopt one or the combination of the three most popular project management methodologies: Kanban, Scrum, and Waterfall.

In this article we have tried to compare these three major methods to shine a light for everyone, what is the difference between them, and how all of them can be beneficial in their own way. This time, we will have a look at the flexibility of the tasks in terms of planning.

Kanban

Kanban is a popular framework used to implement agile and DevOps software development. It requires real-time communication of capacity and full transparency of work.

Work items are represented visually on a Kanban board, allowing team members to see the state of every piece of work at any time.

When planning tasks using the Kanban project management method, you are free to start tasks whenever it is required for the project — it can be next month, next week, tomorrow or in some cases even today.

You can prioritize tasks on the go, if necessary. Sometimes important tasks come up while developing a certain part of the project, which was not foreseen before. For example, something was not thought of when planning tasks, so there is a need for additional tasks that need to be implemented urgently.

This methodology is highly valued for the larger products, where the same team is developing functionalities of a single product for a longer period of time and the project budget is reasonably steady or fixed.

Scrum

The development process in Scrum is split into Sprints, usually, one or two weeks’ plan translated into tasks.

Shorter sprints can be employed to generate more learning cycles and limit the risk of cost and effort to a smaller time frame. Each sprint may be considered a short project.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a product goal at least every two weeks.

You are not allowed to add tasks to the sprint, even if it is a very important one, so it has to wait for the next sprint. Because if you do, there is a risk that your sprint plan will be ruined and the sprint goal will not be reached.

However, sometimes this cannot be avoided since adding tasks or fixing urgent bugs can be a better option for resources and timewise. If you notice that this is happening continuously, consider using Kanban instead!

Waterfall

The Waterfall model is a linear project management approach, where stakeholder and customer requirements are gathered at the beginning of the project, and then a sequential project plan is created to accommodate those requirements.

The waterfall model is so named because each phase of the project cascades into the next, following steadily down like a waterfall.

The Waterfall is even less flexible, as you have to plan the whole project before creating tasks.

Sometimes it is very difficult or even impossible to foresee all the issues for the project, especially if it is a big scope project. So task planning is a very long process, you have to draw various flows, think about every single functionality, process and task.

The key activity in this approach is planning. Every detail of the product should be described in the contract and should be followed constantly. The final product is delivered at the end of the plan at an agreed deadline. Various fixes and improvements should be defined and negotiated afterwards.

Mostly used in projects, when they are very similar to each other, so it is possible to evaluate the extent of each work upfront.

The Waterfall is the least flexible approach out of the above mentioned but, at the same time, the most accurate timeline-wise.

Summary

The Waterfall is a pretty rough and inflexible methodology, but large companies with large scope projects are still using it, because it has a firm structure, resulting in less chaos. All project features, processes, tasks are planned slowly and carefully. This can be a costly way to manage a project, but it is a great way to manage large projects within the limits of time, budget and quality.

The Scrum methodology allows great flexibility in project implementation since the changing requirements and product adaptation is an everyday business for Scrum teams. The team delivers the increment at the end of each Sprint, which allows minimizing the risks, keeping the project within the timeframe and the budget.

The Kanban method may look more chaotic because you can change plans on the go, but it highly depends on the team and project nature. This way of planning projects is more dependent on teams’ experience and skills, the ability to organize themselves and the motivation to deliver quality as soon as possible. However, if the team lacks self-motivation or is inexperienced, it might be more difficult to manage projects using this method.

Overall, all of the aforementioned methodologies have their own advantages and disadvantages, therefore, it is important to understand the nature of your project or product and choose between the three.

But don’t forget, the combination of different methodologies can be a great solution too!

Our example

At CCT we have adapted the combination of the three, although the core comes from the Scrum methodology. We do development in sprints (usually a week-long) allowing us to keep a closer track of the project, meaning that there is a lower possibility to come into a big loss in development if by any chance the wrong step or any misunderstanding would appear.

It might be challenging to produce a working clickable functionality after only one week’s sprint, so sometimes it might be just a showcase of an endpoint returning the correct response, or maybe the production of a drawn schema, but the key is to show progress, and there is always a way to show results. Working in sprints allows for a faster inclusion of key items coming from a client.

Having only the Waterfall approach would be the most efficient planning-wise, although clients like to see the ongoing process and the result usually faster, than a couple of months.

Our approach here is to involve clients in the development process as much as possible, so they are not surprised after all is completed.

For the development team, it is also usually a preference to build a working core of the functionality and then come back to the beautification of it after some time.

The standard Kanban model would leave us as a company not being able to gauge the likely end date of the project, which is not something clients would enjoy. Also, Kanban is too flexible at times, inviting everyone to change their minds often, which could lead to confusion in the development team, misinterpretations between the client and the project team and extended periods of development.

Which project management approach do you prefer? Or do you use a different one? Share your thoughts with us in the comments!

If you have any more questions, feel free to contact us at hello@cornercasetech.com or visit our website: www.cornercasetech.com.