Scrum vs Kanban

Editor's Notes

• #5: If you’re joining me here today, you’re probably already a little bit familiar with the various software development methodologies in the field of software engineering. Debates on various development method pros and cons are countless, but today I want to spend a little time discussing two of the most commonly used methodologies, SCRUM and KANBAN, how they relate to waterfall development as well as their various differences. So let’s begin with a little introduction to Waterfall Development. ‘Waterfall Development’ is another name for the more traditional approach to software development. It’s called ‘waterfall’ as this type of development is often planned using a sequential Gantt chart design– Progress is viewed as flowing downward, you complete one phase (e.g. planning) before moving on to the next phase (e.g. development). Waterfall actually originated in the manufacturing & construction industries.
• #6: In Waterfall approaches, since one phase is completed before moving on to the next phase- you will rarely re-visit a ‘phase’ once it has been completed. As such, it is very important that you get whatever you’re doing right the first time! (JOKE???) This approach is also highly risky, often more costly and generally less efficient than more Agile approaches. The main issues with this approach include problems such as: You won’t realize any real value until the end of the project (when you actually deploy). You leave the testing until the end, which means you’re also leaving issue discovery until late in the project. You don’t seek approval from the stakeholders until later – and their requirements might have changed. You’re heavily reliant upon a plan, which you can and will likely often follow, sometimes to the detriment of the end result of the project. Also, you’re heavily reliant upon a project manager to drive the way of the project – AKA, the power of one. Because of these various issues, skepticism obviously quickly grew and organizations began looking for more efficient development methodologies- such as SCRUM and KANBAN.
• #7: So let’s talk about SCRUM… Scrum is an Agile development framework used for completing complex projects. Scrum originally was created for software development projects, but it works well for any complex, innovative project scope. The possibilities with scrum are endless as the framework is deceptively simple… and we’re going to talk more about that here in just a few moments.But first, one of the key factors of Scrum is that it emphasizes team collaboration and provides a small set of rules that create just enough structure for development teams to be able to focus their innovation on solving what might otherwise be seen as insurmountable challenges. (EXAMPLE?)Scrum gives power to businesses to prioritize and even change development requirements. At the same time, it also gives power to the team to commit to the requirements per their capability.
• #8: So let’s spend a few moments now discussing the SCRUM framework that I mentioned on the previous slide. With SCRUM, you are able to split your development teams up into small cross-functional and self-organizing teams. This allows you to then split your work load into a list of small and concrete deliverables, arranging the list by priorities, where you will then estimate the relative effort to be spent on completing each item. So instead of a large group spending a long time building a big thing, you have a small team spending a short amount of time building a small thing. But integrating regularly to see the whole. Another important aspect of SCRUM is that all the work done is iterative and incremental; splitting time into short fixed-length iterations with potentially shippable code demonstrated after each iteration. (We’ll talk about this in greater detail a little bit later on). SCRUM also allows you to optimize the release plan, which enables development teams to work with the customer in order to update priorities throughout the development process (which Waterfall did not previously allow). Scrum also allows you to optimize the development process and emphasizes feedback: The team can get feedback from the customer as early as possible, and deliver a working product that can/will actually be used. It also allows the team to retrospect on their performance and improve upon it within short cycles.
• #9: Now that we’ve discussed the basics of SCRUM let’s move on to talk about Kanban. Kanban is another technique commonly used for managing a software development process in a highly efficient way. Kanban utilizes Toyota's 'just-in-time' (JIT) production system concept of making "only what is needed, when it is needed, and in the amount needed.“ Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied."Kanban primarily follows four core principles: The first of those 4 core principles is to Visualize the work.This means that you want to create a visual model of work and work flow, in order to observe the flow of work moving through the Kanban system. This can be done by splitting the work into smaller pieces, writing the work item on something such as a piece of paper or index card and putting it up on a task board, using named columns to illustrate where each item is in the development workflow. Making the work visible, along with things such as task blockers, bottlenecks, and queues, instantly leads to increased team communication and collaboration. The next principle is : Limit work in progress, otherwise known as WIPThis means you want to limit how much unfinished work is in progress and reduce the time it takes an item to travel through the Kanban development system. Problems caused by actions such as task switching and the need to constantly reprioritize items can be reduced by limiting WIP. It’s also very important to assign explicit limits to how many items may be in progress at each workflow state. Next, Kanban focuses on flowBy using work in progress (WIP) limits, developing team-driven policies and analyzing the flow of work, the Kanban system can be optimized to improve and smooth out the workflow process, you can collect metrics to analyze flow, and even set indicators that can alert the team of future problems. Focusing on flow will allow teams to measure factors such as lead times or the average time required to complete one item (cycle time). It also allows teams to optimize processes in order to make lead times as small & predictable as possible. The final principle is to : Continuously improveOnce the Kanban system is in place, it becomes the cornerstone for a culture of continuous improvement. Teams measure their effectiveness by tracking flow, quality, throughput, lead times, and more. Experiments and analysis can then be used to change the system to improve the team's effectiveness.
• #10: So that‘s SCRUM and KANBAN in a nutshell. Both are used as development process tools and are implemented in order to accomplish a specific development task or purpose. SCRUM, being more prescriptive with more rules to follow and KANBAN, being more adaptive with fewer rules. So you might now be asking - which is better? SCRUM or KANBAN? The answer isn‘t really black and white- it truly depends on your context. It‘s kinda the same as asking which is better... A knife or fork? Or chopsticks? For eating spaghetti the fork is probably best. For chopping vegetables the knife is probably best. For eating a steak you probably want to use both tools together. For eating Chinese food... well... some prefer a fork while others prefer chopsticks. So when comparing tools you should be careful. Compare for understanding, not for judgment. Basically, neither one is perfect or complete for every circumstance. One or the other won’t depict everything you need to do, they can each only provide certain constraints and guidelines- the true value is found in the fact that both tools help development teams limit options.
• #11: Now I‘d like to talk a little bit about some of the major differences between SCRUM and KANBAN. Hopefully, by doing this I can better help you make a decision as to which process tool is best for you and your individual organization‘s needs. Let‘s begin with the various SCRUM roles. SCRUM consists of three main roles, the product owner, the development team and the SCRUM master. The product owner defines and communicates the product requirements to the development team. They represent the stakeholders and the voice of the customer. One per team is allotted and it‘s their job to prioritize and empathize with the team and stakeholders. Their tasks are things such as demonstrating solutions, announcing releases and organizing milestones. The second role, the development team, delivers the potentially shippable increments of product, otherwise known as PSIs. The team generally consists of 3 – 9 self-organizing team members, all with cross-functional skills, who analyze/design/develop/test, and document the item or task at hand. Last, but most important is the SCRUM master that facilities the SCRUM. This role acts as a buffer between the team and any distactions. They remove project impediments and enforce the SCRUM rules. KANBAN, on the other hand, doesn‘t perscribe any roles, but that doesn‘t mean that you can‘t have a team leader, project manager or even a product owner- it just means you don‘t have to! Be careful when adding roles- ensure that any additional role actually adds value to the project and doesn‘t conflict with other elements of the process. LESS IS MORE!
• #12: Another major difference between SCRUM and KANBAN to be considered are timeboxes. Scrum is based on timeboxed iterations. You can choose the length of the iteration, but the general idea is to keep the same length of iteration over a period of time, thereby establishing what is referred to as a cadence. Cadence means to develop a sustainable pace over multiple sprints, over the course of a project. This cadence establishes a reliable and dependable capability which demonstrates a predictable capacity. Thereby providing confidence in the upcoming work when teams are triggering rather than scheduling work. So let’s talk about these iterations for just a few moments- • At the beginning of an iteration, an iteration plan is created – the team pulls out a specific number of items from the product backlog, based on the product owner’s priorities, and how much the team thinks they can complete in one iteration is determined. • During the iteration, the team focuses on completing the items they committed to. Keeping in mind that the scope of the iteration is fixed. • At the end of the iteration, the team demonstrates the working code to the relevant stakeholders or product owners. Ideally this code should be potentially shippable, meaning that it is tested and ready to go. Then the team does a retrospective to discuss and improve their development process. So in a nutshell- a Scrum iteration is one single timeboxed cadence, combining three different activities: planning, process improvement, and (ideally) release. In Kanban, timeboxed iterations are not prescribed, but you do have the option to include iterations if you so choose. You can choose when to do planning, process improvement, and release. You can even choose to do these activities on a regular basis (“release every monday”) or on-demand (“release whenever we have something useful to release”) .
• #13: Another difference between SCRUM and KANBAN are Tasks and Estimates. In SCRUM, planning meetings are held as we previously talked about- where the SCRUM team will sit down together and determine how much work they feel they can complete in a timebox in order to deliver an increment. In KANBAN, there are no task estimates and as I mentioned before, planning meetings are not a requirement. The team will simply take the next item of order and begin working on that item, until completion.
• #14: Both Scrum and Kanban limit work in progress, but in different ways. Scrum teams usually track velocity – that is how many items (or corresponding units such as “story points”) get completed per iteration. This tracking is intended to help SCRUM teams become better committed to what they achieve during each timebox. Once the team knows their velocity, that becomes their WIP limit (or at least a guideline). For example- A team that has an average velocity of 10 will usually not pull in more than 10 items (or story points) to a sprint. So in Scrum, WIP is limited per unit of time. In Kanban velocity is not tracked, but rather the flow of three things are tracked instead: Queues, WIP, and Cycle times. Queues are the waiting times required for the service to begin on an item. Work in progress, as already discussed, is how many items are currently being worked on (again, WIP is limited per workflow state), And Cycle time is the time it takes for an item to be completed, once the work has begun
• #15: Another big difference between SCRUM and KANBAN, are the process owners. In SCRUM, the process owner is the SCRUM master, whom we talked about earlier on in this webinar. The Scrum master obtains important details about the defined development process and then provides those details to the SCRUM team. In KANBAN, the team owns the process as opposed to one specified leader. There is no fixed defined process, but the team takes the process at hand, provides measures of queues, WIP, and Cycle times- completes the work and then determines how they can continually improve upon their development process.
• #16: Advanages of both... Let‘s just quickly take a look at those before we close out of this session. As you can see, they both provide their own unique advantages such as: Name a few-
• #17: And last but not least… The question organizations often ask is which framework should be used with our teams? Scrum or Kanban? But instead, the question managers should be asking is, which aspects of Scrum and Kanban can we use to effectively develop products and services?Given the advantages of both approaches, it should be up to the development and product teams to choose which framework will work best for them. More recently, some teams have combined both frameworks and used the best practices from each method to achieve better team synergies and improve productivity.There might be teams who feel comfortable with Kanban and others who are more comfortable with Scrum. A better approach could be to coach teams on both frameworks and leave the decision to them to use best practices from both. As we have seen, both Scrum and Kanban are flexible and do not have hardcore processes to be followed, so it could be easy and worthwhile for teams to explore practices from both that enable them to function as highly productive teams that continuously improve.