Scrum vs Kanban
Choosing the right approach can be crucial to the results you achieve. Both are designed to make teams more productive but choosing one is a more complicated decision.
Scrum is used to solve complex problems e.g. building products in a changing environment. Therefore, an empirical approach is important, in which we build on what has been discovered and happened in the past.
Scrum artefacts - Product Backlog/Sprint Backlog/Increment
Product backlog - contains all of the tasks to be completed. The scrum team cannot implement anything that is not included in the Product Backlog. The Product Backlog is managed by the Product Owner.
Sprint backlog - contains the tasks to be done in the current sprint, we define the objective of the sprint and a plan for how we want to do it. The sprint ends with a useful increment.
The Scrum Guide of November 2020 says a Scrum team cannot be larger than 10 people however a recommended 7 +- 2 people assuming the team has complementary skills to complete the project.
As we have described in previous posts, Scrum is distinguished by several pillars. Transparency, Inspection and Adaptation, and all activities should be based on empiricism.
Kanban talks about a set of good practices according to which tasks should be performed.
Visualise the process and tasks - We visualise to see things that may not be visible at first glance. If we performed tasks without thinking through what the process of completion might look like, we would suddenly find that while we were working we had to wait for the right access from the person who was going on holiday or who was carrying out more important tasks at the moment. Visualisation also refers to the graphical representation of progression during work, i.e. Kanban boards in Trello or physical boards with coloured cards of different sizes.
领英推荐
Limiting the amount of work in progress - WIP. It is good practice to limit the maximum number of tasks we complete e.g. each team member cannot have more than three tasks open at the same time. We are keen to make the work of developing elements as productive as possible
Continuous flow management - This practice is directly related to the previous one, as WIP limits are extremely important. It is up to the team members to choose the tasks they are ready to complete. Of course, taking into account the set priorities of the tasks. After time, we may notice tasks that are bypassed by the team. It is worth considering what causes this and react accordingly. It is worth measuring how many tasks are completed in a given period - here we can use Throughput.
Clarity - We are shown another common feature with Scrum. The team needs to have a set of work rules. Starting with a specific Definition of Done, WIP limits, how performance is measured or specific actions when we see a bug on a production version.
Scrum and Kanban share further characteristics, as both have their origins in Agile. No matter what you choose, you must always be ready for change, remember that customer satisfaction caused by continuous and valuable increments is paramount, and working software is the primary measure of progress
Scrum or Kanban will be better for my project?
The subject is more complex than it appears and depends on many factors, and certainly on the team that will do the work. If we want to put it in simple terms:
Kanban is suitable for teams characterised by continuous work - e.g. ticket handling or sales, while Scrum will work great for producing products or services. Of course, we can do both ticketing, sales and marketing in Scrum, but this will require a process alignment. It is also worth mentioning that Kanban has a lower entry threshold, as its requirements for the team are lower than in Scrum.
Although both are agile methodologies, there are differences, as shown in the graphic.
Sometimes is hard to choose #Scrum