The article presents a comparison between Scrum and Kanban. Kanban is becoming an increasingly popular business model today and is now considered an alternative to the Scrum framework in software development.
I will present you with a presentation of Kanban and a comparison between this way of working and Scrum.
I guess many of you already have some idea of the differences between the two methods, but some may be hearing about their existence for the first time.
I want to clarify from now on that the choice of a specific method is related to gaining a specific idea of the problem areas in the organization – what we want to improve.
The choice is also accompanied by a detailed analysis of the organization and processes in the company. I have not had the opportunity to get acquainted with this analysis if it has already been done, nor have I had the opportunity to be present in the discussions on this issue, if any.
In this report, I want to describe the pros and cons, and possibly the difficulties you will encounter with both frameworks.
What is a framework?
Framework means a way of working, a framework. There are hundreds of frameworks, methods, and approaches in management. The choice of a specific Agile framework is subject to the problems that the organization wants to solve. The problems can be different – problems in the structure (levels) of management, lack of clarity in the tasks, unclear communication or lack of established channels of communication, lack of authority, unclear division of roles in the organization, lack of vision and purpose, poor planning and resources or lack thereof, lack of interest – both management and subordinates, inefficiency.
There are different methods to solve these problems, and organizations often decide to combine several.
I would like to emphasize from now on that none of the methods and frameworks gives a specific recipe for how to solve a problem. It all depends on the people – their understanding of the situation and the desire to deal with the problem.
Many of the methods also require a radical change in the way you all work and live – this is not something you should be afraid of. If things don’t work out, it’s not your fault.
Here it is clear that often the problem may be in the work of different teams, but the decision to change is often made at a much higher level. And accordingly the responsibility.
Why should we choose a framework?
As I wrote above – because there is a problem. What I hear from management is that many of you feel ineffective in the workplace. One of the reasons is that ‘there is a lot of work’.
I talked to some of you and realized that quite often you start the month with very little work, and suddenly you are flooded with orders. Others of you said that they often sit at work, frankly without doing anything. Reference: Agile, Scrum and Waterfall project management, ossalumni.org
The management did not share the problem with ‘people who do nothing’ – I am left with the impression that they do not know or do not expect to have any. This makes me think that there is a problem with the flow of information and clear communication between teams and up the hierarchy.
Choosing an Agile framework
A specific model of work will clear many of these, and many other problems that you may not have thought of or do not realize as a problem. Many of these frameworks already have tools in place to deal with them – you may find them unnecessary or exaggerated at first, but believe me – it all matters. Read more: Scrum and Kanban methodologies, vbprojects.org
Things need to change, and change depends only on you – not on you specifically, not on your boss, but all of you together – the teams, the management, HR, everyone. Things will not happen in one day, it takes time, adjustment, and efforts.
As I said, change doesn’t come from outside, you know best where the problem is. No consultant or company will come and tell you how things should be. You are the ones who drive the whole process and have an interest in it. You will try – maybe the first time will not be perfect, but at least you will know what needs to change next time to make things better.
This is the idea of the two frameworks that I will present to you now – to make things better. To become more efficient and willing to come to work and contribute to production.
What is Scrum?
Scrum is a framework, a way of working. The main things in Scrum are artifacts, roles, and events. Remember that none of what I will write now will give you a specific solution to the problems above. Reference: What is Scrum? (BVOP.org)
It’s just a framework, Scrum just gives some rules, objects – like the cards in your board game. And it also gives you some basic (very basic) principles. How you will implement the cards, how you will arrange them, when and who will arrange them, you decide – you, together with your small team. I said the small team – this is one of the main characteristics of Scrum – the small team (maximum 9 people).
The team is at the core of everything. The team owns the work (tasks, backlog) and is responsible for them. The team solves the problems together and autonomously. In a hurry, not your boss, not the director, gives you tasks. You have a goal – an ultimate goal, an achievable goal. You are interested in the goal and you want to achieve it. But you need help – the goal is big and you may not know all its aspects.
But you work in a team – you don’t do the work alone. For those of you who are interested in the theory, I can say that Scrum is described in a modest 19 pages – with a description of all these artifacts, roles, and events, and how it should proceed (by ‘should’ do not mean any very specific and detailed steps and descriptions).
Pretty short, huh? In practice, however, things are quite difficult.
Without going into a cumbersome description of everything in Scrum, I just want to clarify that by choosing this methodology, teams commit to commit certain artifacts (tasks). Ie the team bears collective responsibility if things don’t work out (or if they do :)) and the team – this small team of a maximum of 9 people – is at the heart of everything and the main driver of the work.
Scrum allows for autonomy. Your team is independent of other teams and decides its destiny.
Scrum also provides a great opportunity to discuss the problems that have arisen – within the team itself. It allows for openness and clarity, transparency.
For example, if you are committed to a task but later decide that you need help, you can talk openly about it at the designated meetings (events). Your ‘teammates’ will listen to you, understand the problem, and help you solve it. If, say, you are in a situation where you see that the task takes more than you thought, you can discuss it again.
The core of Scrum is the scrum team – qualities such as loyalty, interest, openness, and striving for success are valued here.
In Scrum, you have the opportunity to go back and compare whether you have become better, more efficient, or not. These things (meetings) are planned and take place in a certain way and with a certain frequency. In Scrum we work with iterations (sprints) – each sprint starts with planning and ends with a demo of the achieved product and retrospective.
There are certain roles in Scrum and they have authority and responsibility for specific things. Each team has a great master – this is the person who plans the meetings and makes sure that the team can do its job on time. He is one of you – he is not your boss, he only helps you. He is interested in your problems and enjoys your success. Other roles are not so important at the moment.
When will Scrum not work?
Implementing Scrum (as well as any other framework) takes time, requires each team member to understand their role and be enthusiastic about change for the better. However, Scrum requires patience. Neither your team will feel the difference in a week or two, nor will your senior management see the benefits in the first place. Reference: Kanban methodology vs Scrum framework, libraryofmu.org
Scrum requires transparency – in communication between people, as well as in scheduling tasks. I see that many of you are embarrassed to talk to each other – perhaps because they are afraid of management or because they do not want to appear as ‘ignorant’ or ‘unqualified’. This is something that needs to be overcome, often requiring a change in the culture of the organization.
Scrum requires rhythm, perseverance, and focus. Discipline. I understand that this may be quite hardcore for some, but it’s all in the name of success. I see that in the organization as a whole there is an understanding that if someone has a question, he ‘just goes and asks’. This works quite often, but costs a lot of resources, the person asked to return to work. You see, one is distracted. I see that the employees in the team are of different ages. Some of you have been through a lot of employers, and now they know how to do the job. This is quite worrying, but I put the blame entirely on senior management for many reasons. The idea is that if someone on the team decides he’s not napping, things just won’t happen.
Scrum requires the team to work on their own and their initiative, and not have someone else ‘make’ them work and mentor them. Scrum does not work if senior management directly intervenes in the decisions and work of individual scrum teams. Read more: What is it like to be a Scrum Master?
Scrum does not work if the tasks are unclear, but it allows them to be clarified in the process of work – this, however, takes time for the specific solution of the task, of course.
What are the benefits of using Scrum?
Scrum contributes to more efficient work, more efficient, and easier to perform processes and tasks. Scrum divides the big goal into small, easy-to-understand, and easy-to-solve tasks. Scrum relies on the interest and involvement of each of you in the common goal.
Scrum will help you ‘clear’ obstacles, streamline processes, work faster, and ‘get in rhythm’. Scrum will lift the spirits of everyone on your team by reducing misunderstandings and unifying expectations for success. Scrum will help you adapt more easily to the often changing environment and/or end goal.
What is Kanban
Kanban is the other better-known framework. In Kanban, it is important to know the amount of work that needs to be done. Accordingly, from this, we can already conclude that if the volume of work is constantly changing, in the process of one cycle of the project, then Kanban may not help you much. Reference: Kanban methodology vs Scrum framework
My personal opinion is that Kanban can be used to give status to work at a higher level – to senior management. And from experience, I dare say that many companies use Scrum – at the level of Scrum team, where there are many such teams, and at the same time Kanban, as a means of communication with senior management. Read more: Kanban vs Scrum? What Are the Differences Between Scrum and Kanban? scrumtime.org
The important thing in Kanban is that the volume of work includes all levels from the production itself, through test and approval. Here things are very different, imagine that a product is manufactured and is in the test stage, but there is a problem with the test technology, which means that the product must be repeatedly “returned” to the test stage.
Here it is important to assess the real situation and how long it will take to complete the test (in this particular situation). If this is not possible – due to ignorance, lack of funds, or technology, it will be very difficult to improve the process with Kanban. Reference: Kanban vs. Scrum: What Are the Differences Between Scrum and Kanban, eduwiki.me
Of course, this is relevant for all other stages of production, not just a test. The real evaluation of the tasks is important. This depends on how specific and detailed the tasks are set, as well as on the skills and experience of the team that performs them. This rating should not be overestimating or deliberately underestimating – it will not help you at all. The real assessment is important here.
Kanban is used precisely to prevent the allocation of unnecessary resources for things that can be done cheaper and easier and faster.
That is why I believe that Kanban is more typical for reporting to senior management. They do not care if the specific task is obtained, developed, tested. Management is interested in the final product and whether (and when) it will be available. Management is also interested in how many of the workloads have been completed. But managers don’t care how people have communicated, how they have improved their processes – they are interested in the man-hours used for that.
There are no roles or events in Kanban.
There are no meetings for discussion in the small team. Accordingly, all the things that can be achieved and improved in terms of teamwork are gone. Or at least they are at a much less developed level. However, whether this is necessary depends on the specific problems, culture, and structure of the organization.
As you can see from all that has been written, I cannot give a specific answer as to whether Kanban or Scrum is more relevant to you. This decision will be made soon, in a narrow circle of management and me, after a specific analysis of the situation and problems of the organization.
Whether you choose one or the other depends on the problem or problems you want to solve. During the week I was here, I talked to both you and some of your employees – the things I hear are quite diverse and that is why I want to suggest that you make a clearer analysis of the problems. This can happen, for example, by planning several workshops with representatives from different levels.
Read more: Build an Agile Kaizen strategy and methodology with 20 keys to workplace improvement
Processes in Kanban are related to a real assessment of the volume of work. I see that employees often complain that they do not know ‘what will come tomorrow’. By better planning and involving all participants in the production process, I hope you can solve this so that the amount of work can be predicted. If this is not possible, Kanban is not the right solution.
Also, keep in mind that both Kanban and Scrum require trust and an attitude to change for the better. This can take time, especially in an organization like yours – you’re a pretty big team.
Trust is naturally problematic – this is typical of large organizations, but it can be remedied with more conversation and openness.
Regarding the teams – at Kanban there are no rules about how big a team is, there are no roles. Here, however, keep in mind that teams should naturally be commensurate, homogeneous, and not too large – this would make any planning difficult. I see that there is a big discrepancy in this in your organization – some teams number 15-20 people, others have 5. I understand that this is consistent with your work, but it depends on the choice of a specific framework for work.
Scrum is much clearer about teams and roles and decision-making, in my opinion. At Scrum, we have a clear, autonomous, and small team. By choosing Scrum, this means that senior management – including you, will not have a direct role in decision-making and the way Scrum teams work.
Of course, they will not ignore you, but the intervention will not be direct and may take longer. At Scrum we have a clear loyalty to the team – people work in the team, for the team (only this one team) and are obviously interested and directly involved in solving specific tasks.
Scrum requires (Kanban – too) a change of mindset. I see that there is quite a big age difference in your employees. I guess for some of them it will be quite difficult to ‘adapt’ to the new. I think you have to work on that if you want Scrum to work for you. At Scrum, we have the so-called sprints or iterations that are 14 days each. This means that at the end of each sprint, the team must have produced the so-called minimum viable product. You need to clarify whether this ‘rhythm’ of work is appropriate for your organization, given the product you are developing.
There are quite clear-cut events at Scrum. Every sprint starts with planning – here you need to know how much work needs to be done for the next 14 days, which means that there can be no ‘surprises’ in the middle of the sprint.
I also want to clarify that in addition to the autonomy of the teams, Scrum provides the opportunity for more creativity and creativity – all this is based on constant and timely discussions in the small team.
In conclusion, I want to go back to what I wrote at the beginning. I would like to recommend that you do a thorough in-depth analysis of the specific problems you want to solve before deciding whether it will be Scrum, Kanban, or something else.
Both Agile frameworks can often work at the same time – it all depends on your desire and the goal or expectations of the model itself, on what exactly you want to get as a result of your choice. And whether it will be for yourself, as a director, or for some other group of employees.