Speaker 1: Hi guys, welcome to this live session on scrum vs kanban. Now, we'll just get started in a little bit. Let's wait while people join in. Hey guys, welcome again to this live session on scrum vs kanban. I'd like to thank everyone joining in from Facebook and YouTube. Also, if you guys have any questions, let us know in the live chat. We have a dedicated team here to answer all your doubts. So without further ado, let's jump into scrum vs kanban. So before we dive into the differences between scrum and kanban, let's have a look at what exactly scrum is. Scrum is a simple agile project management framework that is used by organizations to help teams collaborate, handle unpredictability, and complex projects or products while ensuring the products delivered are of the highest value. It describes a set of meetings, tools, and roles that enable teams to work in sync and help them structure themselves and manage their work. Scrum is one of those things that's really easy to understand but very difficult to master. And although scrum is seen to be used generally by software development teams, its principles and themes are pretty universal and can be used with just about all kinds of teamwork. With scrum, teams are able to learn from their experiences. What worked out, what didn't and things like that. They're also able to organize themselves to handle their problems effectively and basically improve themselves by reflecting on them. So how does scrum work? Here we have the first component, the product backlog. The product backlog consists of a list of tasks that need to be completed so that the goals of the stakeholders are achieved. Then the team decides what tasks from the product backlog they want to take up and deliver in a 2-4 week period, called sprint, hence the name sprint planning. Next, the tasks that were discussed in the previous phase are added to the sprint backlog. This is a set of tasks which will be focused on in the ongoing sprint. Following this, the scrum team, which is usually 5-9 members strong, will work on these tasks. Now they also have regular scrum meetings where they talk about their victories, the issues they face and what they plan to do in the next 24 hours. And then they have the sprint review. The sprint review is a meeting during which the team shows what they accomplished during the sprint. Now during this time, questions are asked, observations, feedback and suggestions are made. The product owner also gets feedback for upcoming sprints from stakeholders. They also have a sprint retrospective. Now during this session, past mistakes, potential issues and new ways to handle them are identified. Data from here is incorporated into the new sprint plan. The final step is increment. Here a workable and usable output is provided to the stakeholders. So now that we know how scrum works, let's have a look at Kanban. Kanban comes from the Japanese word Kanbam which literally means signboard. Like scrum, Kanban is a popular agile framework i.e. a visual system by which the work can be managed with ease as it progresses. Kanban uses something known as the Kanban board to make these things possible. With this, you can easily identify bottlenecks and then fix them cost-effectively at optimal speeds. The main focus with Kanban is transparency. Since everything related to the tasks are on the board, everyone can keep themselves updated. It also ensures that teams focus on their current tasks until they're done. This limits the amount of work that's in progress. So on the Kanban board, work is divided into smaller, more manageable pieces. The work that's needed to be done is written on a note or card and placed on a board. Columns on the board help represent where each item is, with respect to the workflow. Now let's have a look at what these are in detail. Let's find out how Kanban works. Now the board consists of three major components. There's the to-do list which represents items that need to be completed. The ongoing column which represents items that are being currently worked on. And the completed or the done column. Now these represent tasks or items that have already been completed. Now although this is a physical representation of the board, several organizations use software versions of the board that replaces the sticky notes with cards that can be moved from one column to another as work progresses. Now an example of such a software is Trello. So if you want to learn more about Trello, you can check out the link I'll be adding to the live chat in a moment. At this point, you guys must have realized how similar these two frameworks sound. So let's run through some more of their similarities. Let's find out how they are similar. Firstly, they both have principles of Lean and Agile, which means reduction of waste and both of them are time-boxed and iterative approaches that enable product delivery in an incremental manner. Both these frameworks aim to reduce the amount of work in progress. This forces the teams to ensure that they focus on a smaller set of tasks. This also makes blockers and bottlenecks a little more visible. In both cases, the work is divided into smaller, more manageable units. Both of these frameworks use pull scheduling. This means that products are only built based on demand rather than forecasts. Transparency plays a major role in both these frameworks by helping them drive process improvement. And in both cases, the release plan is continuously optimized and finally, both these methods aim to deliver releasable software often and earlier than expected. So now that we've reached midway, let me ask you guys a question. Do you guys use Scrum or Kanban in your workplace or do you use these software for personal reasons? What exactly do you use these for? Let me know in the live chat. Now, let's have a look at how these two frameworks are different from one another. Firstly, let's have a look at Cadence. Cadence refers to the amount of time in a sprint or before a release. So when it comes to Scrum, the entire project is divided into time-constrained iterations. That is, into smaller, manageable units. But when it comes to Kanban, it's event-driven. Next criteria we are going to have a look at is Release Methodology. In Scrum, releases take place after each sprint, which usually takes 2-4 weeks to complete. For Kanban, releases take place in the form of continuous delivery. They happen in such a way that changes like new features, configuration changes, bug fixes and experiments get to the users in a safe, quick and sustainable manner. Next up, let's have a look at how changes are addressed in both these frameworks. In Scrum, no change can be made while the sprint is in progress. Once it's complete, changes can be considered in the sprint plan and then added to the sprint backlog. With Kanban, changes can be made at any time and incorporated into the workflow. Now let's consider the metric that's being measured. In Scrum, for planning and process improvement, velocity, which is the measure of the work that can be completed by a team in a sprint, is the key metric. In Kanban, lead time is the key metric. This represents the period of time between a new task's appearance in your workflow and its final departure from the system. Next, let's have a look at how teams work in these frameworks. In Scrum, you need a cross-functional team to achieve your goals in a sprint. In Kanban, cross-functional teams are optional but specialized teams that focus on particular aspects of the workflow are required. Now let's talk about new additions. In Scrum, just like handling changes, you can't add any items between a sprint or night ration. In Kanban, new items can be added to the board as long as there's capacity available for it. Now let's have a look at the job roles within these frameworks. Scrum has three major job roles. Product Owner, Scrum Master and Scrum Team. With Kanban, you don't have any specific job roles. Now let's talk about representation. Or moreover, let's talk about how data can be represented. With Scrum, the board needs to be reset once a particular sprint is complete. With Kanban, the board stays persistent throughout the entirety of the project. And finally, let's have a look at project length. With Scrum, it's better suited for longer projects. And with Kanban, projects that can be completed in a shorter period of time are better. So which one should you choose? Now selecting from these two methods is mainly based on the requirements of the team. Do you expect your project to be shorter? Do you want to make changes at any time? If you don't want to set up job-specific roles, then Kanban is the framework for you. Or do you want a long-running project with different job roles and involving cross-functional teams? Scrum is the answer for you. Based on the differences we discussed in the last topic, you can make an informed decision. Now let's have a look at some of the popular companies around the world that employ both these frameworks. Some of the companies that have successfully implemented Scrum are Facebook, General Electronics and Adobe. Companies that have implemented Kanban are Siemens, BBC and SAP. And there you go, we have laid out the facts for you. Keep in mind your requirements and make a wise choice. Let us know what you pick and why in the live chat or in the comments section below. We hope you guys found this informative and helpful. Don't forget to subscribe, sanitize and stay safe. Thank you for watching and stay tuned for more from Simply Learn. Bye.