As an expert software development team that designs the most complicated software solutions for our customers, we always face a choice which Agile framework we should choose. Some tasks can be easily solved by SCRUM, sometimes Kanban provides us with the optimal solutions. Let’s go deeper to find the answer to the question, what framework to choose.

SCRUM or Kanban
The most well-known and widely used Agile frameworks are SCRUM and Kanban. SCRUM suggests we work on the development of the project iteratively. At the end of each iteration, which lasts about a couple of weeks, we have the finished simple version of the software product that we can deliver to the customer. Before starting the first iteration, which is called Sprint, our team of developers has to assign roles and plan thoroughly these two weeks and then, during a Sprint, meet daily to organize essential interaction within the team. Since it is an Agile framework, we should insert modifications according to customers’ feedback and changes in an environment. However, here we are allowed to do it only between Sprints, and no changes can be made within one iteration.

As for Kanban, its main idea is to put all the issues together, and use a board with columns called “to do”, “in progress” and “done” to systematize the development tasks. Here we visualize our issues with stickers and put them in the column that corresponds to the status of the task. In Kanban we have no roles for our team members, they are all equivalent. Moreover, any changes can be inserted at any time and anyone from our team, or from the client’s side can suggest them. So, this framework, on the one hand, is much more flexible, but, on the other hand, contains some hidden problems such as it has no exact time when the product will be ready and the project is completed.

Some hybrid methods as Scrumban propose us to use a combination of these two approaches, such as iterative work, where Sprint is organized according to Kanban principles.

So, when should we prefer using the first one, and when does the second one fit much better? Or should we choose Scrumban and other hybrids?

Is SCRUM the right thing to choose?
SCRUM is a great option when a customer has no exact understanding of the market needs and wishes to be flexible with the software changes, providing regular feedback about further improvements and functional and non-functional demands. In this case, we can accurately estimate the work to do and the team is able to work cooperatively. However, there are multiple requirements that our team and project need to meet to work in SCRUM workflow productively.

Let’s look at an example of the data science project. Here we have a concrete set of tasks to be done, from point one, setting the hypothesis, choosing the models, and training them to the final step, when we have to choose the best working model and finalize the work with the whole database, collecting the results. Here is nothing about SCRUM iterations or KanBan ToDos. It’s a structured Waterfall process. All in all, data science projects are just one of the examples where SCRUM is not really convenient. We always need to estimate whether this framework fits our project well.
The other, more basic example, which can explain why we should abandon the idea of using SCRUM in some projects, also Data Science ones, is plane construction. The reason here is a lack of possibility of customers’ feedback. We have to make our plane safe, convenient, and flying. We cannot build just its carcass and ask the customer for its opinion and desirable changes. The customer will risk their life to estimate it. Here we have to work with some models similar to Waterfall: firstly to plan everything, then to make it functional and flying, then to test it multiple times and only after to start thinking about customer comfort and not to try working on all those steps at the same time. The same problem we stalk in the case of developing Data Science and other software sometimes. Firstly, we need to make a software that performs the task, then to test it and only after to improve its user convenience. So, one of the main reasons when SCRUM sucks is when customers cannot provide needed feedback.

Is Kanban the right thing to choose?
First of all, Kanban always wins when we have to have a chance to insert changes at any time or to change the priorities of tasks in our project. Kanban makes it realizable if it is needed, for example, if we have no data for the exact estimation of time needed. However, there is a range of things that Kanban cannot deal with. If you are going to use Kanban to avoid retrospectives, deadlines, interaction within a team, or dealing with tasks of different values. All these points are necessary and important for Kanban as well as for SCRUM. You still have to be able to analyze what should be changed in the future. Without a hard-working stable team, no good result can be obtained. Furthermore, when SCRUM demands us to set deadlines when there are no of them in Kanban, but we have to be ready to make a release at any time. Another key point is that tasks shouldn’t variate in value too much, instead, we have to be able to divide them into smaller tasks. Our team has to have a shared view on the project and we should work on this same vision really hard. We shouldn’t push our team to work with Kanban, but it needs to understand the key principles of that framework and realize the necessity for the work to be done by that approach. Otherwise, despite Kanban's simplicity, we cannot provide productive work by that method.

Conclusion
As such, Agile approaches lead us to be able to make any changes that depend on the environment. However, it demands great time management and interaction within a team. So, it is not only the problem that our team should be ready and well-prepared to use it, but also we face the problem that we need to develop a deep understanding if this or another framework really fits our needs and can solve our problems.