SOFTWARE ENGINEERING
A REPORT ON :
SCRUM VS KANBAN REPORT
Scrum Methodology
What Is Scrum?
Scrum is a subset of Agile and one of the most popular process frameworks for implementing Agile. It is an initial software development model used to manage complex software and product development. Fixed-length iterations, called sprints lasting one to two weeks long, allow the team to ship software on a regular cadence. At the end of each sprint, stakeholders and team members meet to plan next steps.
Scrum follows a set of roles, responsibilities, and meetings that never change. For example, Scrum calls for four ceremonies that provide structure to each sprint:
sprint planning, daily stand-up, sprint demo, and sprint retrospective. During each sprint, the team will use visual artifacts like task boards or burndown charts to show progress and receive incremental feedback.
Jeff Sutherland created the Scrum process in 1993, taking the term “Scrum” from an analogy in a 1986 study by Takeuchi and Nonaka published in the Harvard Business Review. In the study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the Scrum formation used by Rugby teams. The original context for this was manufacturing, but Sutherland, along with John Scumniotales and Jeff McKenna, adapted the model for software development.
Advantages of Scrum
Scrum is a highly prescriptive framework with specific roles and ceremonies. While it can be a lot to learn, these rules have a lot of advantages. The benefits of Scrum include:
⦁ More transparency and project visibility: With daily stand-up meetings, the whole team knows who is doing what, eliminating many misunderstandings and confusion. Issues are identified in advance, allowing the team to resolve them before they get out of hand.
⦁ Increased team accountability: There is no project manager telling the Scrum Team what to do and when. Instead, the team collectively decides what work they can complete in each sprint. They all work together and help each other, improving collaboration and empowering each team member to be independent.
⦁ Easy to accommodate changes: With short sprints and constant feedback, it’s easier to cope with and accommodate changes. For example, if the team discovers a new user story during one sprint, they can easily add that feature to the next sprint during the backlog refinement meeting.
⦁ Increased cost savings: Constant communication ensures the team is aware of all issues and changes as soon as they arise, helping to lower expenses and increase quality. By coding and testing features in smaller chunks, there is continuous feedback and mistakes can be corrected early on, before they get too expensive to fix.
Disadvantages of Scrum
While Scrum offers some concrete benefits, it also has some downsides. Scrum requires a high level of experience and commitment from the team and projects can be at risk of scope creep.
Here are the disadvantages of Scrum:
⦁ Risk of scope creep: Some Scrum projects can experience scope creep due to a lack of specific end date. With no completion date, stakeholders may be tempted to keep requesting additional functionality.
⦁ Team requires experience and commitment: With defined roles and responsibilities, the team needs to be familiar with Scrum principles to succeed. Because there are no defined roles in the Scrum Team (everyone does everything), it requires team members with technical experience. The team also needs to commit to the daily Scrum meetings and to stay on the team for the duration of the project.
⦁ The wrong Scrum Master can ruin everything: The Scrum Master is very different from a project manager. The Scrum Master does not have authority over the team; he or she needs to trust the team they are managing and never tell them what to do. If the Scrum Master tries to control the team, the project will fail.
⦁ Poorly defined tasks can lead to inaccuracies: Project costs and timelines won’t be accurate if tasks are not well defined. If the initial goals are unclear, planning becomes difficult and sprints can take more time than originally estimated.
Roles in Scrum
There are three specific roles in Scrum. They are:
⦁ Product Owner: The Scrum Product Owner has the vision of what he or she wants to build and conveys that vision to the team. The Product Owner focuses on business and market requirements, prioritizing all the work that needs to be done. He or she builds and manages the backlog, provides guidance on which features to ship next, and interacts with the team and other stakeholders to make sure everyone understands the items in the product backlog. The Product Owner is not a project manager. Instead of managing the status and progress, his or her job is to motivate the team with a goal and vision.
⦁ Scrum Master: Often considered the coach for the team, the Scrum Master helps the team do their best possible work. This means organizing meetings, dealing with roadblocks and challenges, and working with the Product Owner to ensure the product backlog is ready for the next sprint. The Scrum Master also makes sure the team follows the Scrum process. He or she doesn’t have authority over the team members, but he or she does have authority over the process. For example, the Scrum Master can’t tell someone what to do, but could propose a new sprint cadence.
⦁ Scrum Team: The Scrum Team is comprised of five to seven members. Everyone on the project works together, helps each other, and shares a deep sense of camaraderie. Unlike traditional development teams, there are not distinct roles like programmer, designer, or tester. Everyone completes the set of work together. The Scrum Team owns the plan for each sprint; they anticipate how much work they can complete in each iteration.
Steps in the Scrum Process
There are a specific, unchanging set of steps in the Scrum flow. They include:
⦁ Product backlog: The Product Owner and Scrum Team meet to prioritize the items on the product backlog (the work on the product backlog comes from user stories and requirements). The product backlog is not a list of things to be completed, but rather it is a list of all the desired features for the product. The development team then pulls work from the product backlog to complete during each sprint.
⦁ Sprint planning: Before each sprint, the Product Owner presents the top items on the backlog to the team in a sprint planning meeting. The team then chooses which work they can complete during the sprint and moves the work from the product backlog to the sprint backlog (which is a list of tasks to complete in the sprint).
⦁ Backlog refinement/grooming: At the end of one sprint, the team and Product Owner meet to make sure the backlog is ready for the next sprint. The team may remove user stories that aren’t relevant, create new stories, reassess the priority of stories, or split user stories into smaller tasks. The purpose of this “grooming” meeting is to ensure the backlog only contains items that are relevant and detailed, and that meet the project’s objectives.
⦁ Daily Scrum meetings: The Daily Scrum is a 15-minute stand-up meeting where each team member talks about their goals and any issues that have come up. The Daily Scrum happens every day during the sprint and helps keep the team on track.
⦁ Sprint review meeting: At the end of each sprint, the team presents the work they have completed at a sprint review meeting. This meeting should feature a live demonstration, not a report or a PowerPoint presentation.
⦁ Sprint retrospective meeting: Also at the end of each sprint, the team reflects on how well Scrum is working for them and talks about any changes that need to be made in the next sprint. The team may talk about what went well during the sprint, what went wrong, and what they could do differently.
Tools, Artifacts, and Methods in Scrum
In addition to roles and ceremonies, Scrum projects also include certain tools and artifacts. For example, the team uses a Scrum board to visualize the backlog or a burndown chart to show outstanding work. The most common artifacts and methods are:
⦁ Scrum board: You can visualize your sprint backlog with a Scrum task board. The board can have different forms; it traditionally involves index cards, Post-It notes, or a whiteboard. The Scrum board is usually divided into three categories: to do, work in progress, and done. The Scrum Team needs to update the board throughout the entire sprint. For example, if someone comes up with a new task, she would write a new card and put it in the appropriate column.
⦁ User stories: A user story describes a software feature from the customer’s perspective. It includes the type of user, what they want, and why they want it. These short stories follow a similar structure: as a <type of user>, I want to <perform some task> so that I can <achieve some goal.> The development team uses these stories to create code that will meet the requirements of the stories.
⦁ Burndown chart: A burndown chart represents all outstanding work. The backlog is usually on the vertical axis, with time along the horizontal axis. The work remaining can be represented by story points, ideal days, team days, or other metrics. A burndown chart can warn the team if things aren’t going according to plan and helps to show the impact of decisions.
⦁ Large-Scale Scrum (LeSS): If you want to scale elements of Scrum to hundreds of developers, the Large-Scale Scrum (LeSS) framework helps extend the rules and guidelines without losing the core of Scrum. The principles are taken directly from Scrum, however focuses on scaling up without adding additional overhead (like adding more roles, artifacts, or processes).
⦁ Timeboxing: A timebox is a set period of time during which a team works towards completing a goal. Instead of letting a team work until the goal is reached, the timebox approach stops work when the time limit is reached. Time-boxed iterations are often used in Scrum and Extreme Programming.
⦁ Icebox: Any user stories that are recorded but not moved to development are stored in the icebox.
The term “icebox” was created by Pivotal Tracker, an Agile project management tool.
⦁ Scrum vs RUP: While both Scrum and Rational Unified Process (RUP) follow the Agile framework, RUP involves more formal definition of scope, major milestones, and specific dates (Scrum uses a project backlog instead of scope). In addition, RUP involves four major phases of the project lifecycle (inception, elaboration, construction, and transition), whereas Scrum dictates that the whole “traditional lifecycle” fits into one iteration.
⦁ Lean vs Scrum: Scrum is a software development framework, while Lean helps optimize that process. Scrum’s primary goal is on the people, while Lean focuses on the process. They are both considered Agile techniques, however Lean introduces two major concepts: eliminating waste and improving flow.
How to Get Started with Scrum
Working with Scrum often means changing the team’s habits. They need to take more responsibility, increase the quality of the code, and boost speed of delivery. This level of commitment acts as a change agent; as the teams commit to sprint goals, they are more and more motivated to get better and faster to deliver a quality product.
A good place to start with Scrum is to talk about the roles. Every project must have a Scrum Master, Product Owner, and Scrum Team. You may want to talk about who should be the Scrum Master and Product Owner, or if these roles are already assigned, you may want to clarify their roles and responsibilities.
Depending on how familiar your team is with Scrum, you may also want to look into training sessions. Certified Scrum Coaches and Trainers and Scrum Alliance Registered Education Providers can help your team learn and embrace Scrum.
Smartsheet's newest view, Card View, gives Agile teams a more highly-visual way to work, communicate, and collaborate in Smartsheet. Card View enables you to focus attention with rich cards, give perspective with flexible views, and prioritize and adjust work more visually. Display information on cards including custom fields, images, and color coding to better focus your team’s attention. Categorize cards into lanes to organize your work more visually.
Kanban
What Is Kanban?
Kanban is Japanese for “visual sign” or “card.” It is a visual framework used to implement Agile that shows what to produce, when to produce it, and how much to produce. It encourages small, incremental changes to your current system and does not require a certain set up or procedure (meaning, you could overlay Kanban on top of other existing workflows).
Kanban was inspired by the Toyota Production System and Lean Manufacturing. In the 1940s, Toyota improved its engineering process by modeling it after how supermarkets stock shelves. Engineer Taiichi Ohno noticed that supermarkets stock just enough product to meet demand, optimizing the flow between the supermarket and customer. Inventory would only be restocked when there was empty space on the shelf (a visual cue). And because inventory matched consumption, the supermarket improved efficiency in inventory management.
Toyota brought these same principles to its factory floors. Different teams would create a card (or Kanban) to communicate that they had extra capacity and were ready to pull more materials. Because all requests for parts were pulled from the order, Kanban is sometimes called the “pull system.”
These same ideas apply to software teams and IT projects today. In this context, development work-in-progress (WIP) takes the place of inventory, and new work can only be added when there is an “empty space” on the team’s visual Kanban board. Kanban matches the amount of WIP to the team’s capacity, improving flexibility, transparency, and output.
According to the Kanban blog, “Kanban is a technique for managing a software development process in a highly efficient way. Kanban underpins Toyota's ‘just-in-time’ (JIT) product system. 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.”
When looking at Kanban vs Agile, it’s important to remember that Kanban is one flavor of Agile. It’s one of many frameworks used to implement Agile software development.
About the Kanban Board
A Kanban board is a tool to implement the Kanban method for projects. Traditionally, this tool has been a physical board, with magnets, plastic chips, or sticky notes on a whiteboard to represent work items. However, in recent years, more and more project management software tools have created online Kanban boards.
A Kanban board, whether it is physical or online, is made up of different swim lanes or columns. The simplest boards have three columns: to do, in progress, and done. The columns for a software development project may consist of backlog, ready, coding, testing, approval, and done columns.
Kanban cards (like sticky notes) represent the work and each card is placed on the board in the lane that represents the status of that work. These cards communicate status at a glance. You could also use different color cards to represent different details. For example, green cards could represent a feature and orange cards could represent a task.
Advantages of Kanban
Kanban’s visual nature offers a unique advantage when implementing Agile. The Kanban board is easy to learn and understand, it improves flow of work, and minimizes cycle time.
The advantages of Kanban include:
⦁ Increases flexibility: Kanban is an evolving, fluid model. There are no set phase durations and priorities are reevaluated as new information comes in.
⦁ Reduces waste: Kanban revolves around reducing waste, ensuring that teams don’t spend time doing work that isn’t needed or doing the wrong kind of work.
⦁ Easy to understand: The visual nature of Kanban helps to make it incredibly intuitive and easy to learn. The team doesn’t need to learn a completely new methodology, and Kanban can be easily implemented on top of other systems in place.
⦁ Improves delivery flow: Kanban teams optimize the flow of work out to customers. Like continuous delivery (CD), Kanban focuses on the just-in-time delivery of value and delivering work to customers on a regular cadence.
⦁ Minimizes cycle time: Cycle time is the amount of time it takes for work to move through the team’s workflow. In Kanban projects, the entire team helps to ensure the work is moving quickly and successfully through the process.
Disadvantages of Kanban
Many of the disadvantages associated with Kanban come with misuse or mishandling of the Kanban board. An outdated or overcomplicated board can lead to confusion, inaccuracies, or miscommunication.
Here’s more on the disadvantages of Kanban:
⦁ Outdated board can lead to issues: The team must be committed to keeping the Kanban board up to date, otherwise they’ll be working off inaccurate information. And once work is completed based off an out-of-date board, it can be hard to get things back on track.
⦁ Teams can overcomplicate the board: The Kanban board should remain clear and easy to read, however some team members may learn “new tricks” they can apply to their board. Adding these kinds of bells and whistles to the Kanban board just buries the important information.
⦁ Lack of timing: A frequent complaint about Kanban is that you don’t know when things will be done. The columns on the Kanban board are only marked by phase (to do, in progress, complete), there are no timeframes associated with each phase, so you really don’t know how long the to do phase could last.
Core Practices and Principles of Kanban
Every Kanban project should follow these core principles:
⦁ Visualize the workflow: A visual representation of your work allows you to understand the big picture and see how the flow of work progresses. By making all the work visible, including blockers and queues, you can identify issues early on and improve collaboration.
⦁ Limit work in progress (WIP): Work in progress limits (WIP limits) determine the minimum and maximum amount of work for each column on the board or for each workflow. By putting a limit on WIP, you can increase speed and flexibility, and reduce the need for prioritizing tasks.
⦁ Manage and enhance the flow: The flow of work (the movement of work) throughout the Kanban board should be monitored and improved upon. Ideally, you want a fast, smooth flow, which shows that the team is creating value quickly. The team should analyze problems in the flow then implement changes.
⦁ Make process policies explicit: In order for collaborative change to occur in the Kanban system, the processes need to be explicit. Everyone needs to understand how things work or what “done” really means. You can modify the board to make these processes more clear; for example, you could redesign it to specify how the work should flow.
⦁ Continuously improve: The Kanban method encourages small, continuous changes that stick. Once the Kanban system is in place, the team will be able to identify and understand issues and suggest improvements. Teams measure their effectiveness by tracking flow, measuring cycle time, and increasing quality of work.
Common Questions About Kanban
Q: How do you organize meetings and maintain focus without a Scrum Master?
Someone on the team needs to take initiative to put the meeting on the calendar and ensure the conversation stays on track. Even without a Scrum Master, it normally isn’t too big of an issue.
The Kanban board helps maintain focus during the meeting. During the meeting, you can go through the board from left to right and look for stories that have not moved since the last meeting. Instead of talking about accomplishments, you can just look at the cards on the board. The one question you do need to ask during a meeting is about the roadblockers or challenges to getting an item finished.
You could also try a kaizen meeting, where you only invite people who are involved in the task at hand. Each person discusses problems and challenges, and how his or her job could be done more efficiently. Then, the whole group talks about solutions to those issues.
Kaizen also can include a kaizen facilitator, who encourages the team to openly discuss critical issues.
Q: How can Kanban satisfy management’s desire for predictable delivery?
To some extent, Kanban trades predictability for efficiency. There are no timebox constraints or planning, however once a team has optimized the flow of work and can get a sense of how long certain tasks take, there will be some level of predictability.
If management still needs more defined predictability (which is not the Kanban approach), you may need to try managing expectations. In a traditional model, you have a predictable date of delivery, but in reality, no one is going to deliver a product by that date if it’s not complete. Management is always going to wait for the product to be complete, regardless of the original date set. In the Kanban model, the expectations need to be adjusted to focus on delivering the product when it’s ready and complete.
Q: How do you use Kanban when you’re on a deadline?
There are a couple different ways you can handle deadlines in a Kanban model. You can simply write the deadlines on the Kanban cards, making sure these deadlines act more as guidelines rather than hard-and-fast due dates (in Kanban, you shouldn’t sacrifice quality for timing).
You could also change how you and your team approach deadlines. In Kanban’s truest form, there is no need for them. The Kanban system will make sure that all tasks are completed as soon as possible, so a deadline is no longer necessary.
Q: Can Kanban be used for other projects besides software development?
Yes, Kanban can improve process results, reduce production times, and help manage workflow in almost any industry. For example, in the game development industry, Kanban helps shorten the video process timeline and reduce waste. In real estate, it brings more efficiency by tracking contracts, prospects, and listings on various boards. And in finance, Kanban can quickly identify bottlenecks and increase speed-to-market.
Q: Is WIP driven by resource availability?
Yes. When setting WIP limits, you need to look at how many people you have on your team and how many tasks you want them to work on at the same time.
Q: How do you know if the WIP limit is correct?
There is no formula for setting the right WIP limits. It’s very common for limits to be wrong in the beginning, but you just need to adjust them as the project progresses. A good place to start is 1.5 for available resource, but you should constantly be reevaluating this number and making changes as necessary.
Kanban vs Scrum
Differences and Similarities: Scrum vs Kanban
Scrum and Kanban are both flavors of Agile, but they have some distinct differences.
⦁ Scrum requires specific roles whereas Kanban has no required roles.
⦁ Scrum is based on timeboxed iterations, combining planning, process improvement, and release. In Kanban, you can choose to do these activities on a regular cadence or whenever you need.
⦁ Scrum limits work in progress (WIP) in each iteration, whereas Kanban limits WIP in each workflow.
⦁ Scrum resists change, whereas Kanban easily accommodates and embraces change. In Scrum, once the team has committed stories to a sprint, you can’t add additional stories later on. In Kanban, you can add or change stories as you please, assuming that it’s within WIP limits.
⦁ A Scrum board is reset after each sprint. A Kanban board is continuously used.
⦁ A Scrum team is cross-functional and one team owns the Scrum board. In Kanban, teams don’t need to be cross-functional and anyone can own the Kanban board.
⦁ Scrum teams require estimation, whereas Kanban doesn’t.
And Scrum and Kanban also have some similarities:
⦁ They are empirical. You have to experiment with the process to see what works for you.
⦁ Both allow team members to work on multiple products at once.
⦁ They are Lean and Agile.
⦁ They both limit WIP (although the way they each limit WIP is different)
⦁ They use pull scheduling
⦁ They focus on delivering software early and often
⦁ Both use transparency to improve process
How Do Kanban and Scrum Relate to Each Other?
Kanban and Scrum are both frameworks for Agile software development. They both take large, complex tasks and break them down into smaller chunks. Kanban and Scrum also work toward continual improvement and optimization of the process, and want to keep work highly visible.
While both Kanban and Scrum are very adaptive, Scrum is more rigid than Kanban. Scrum has more constraints, whereas Kanban is more flexible.
Scrum Board vs Kanban Board
While a Scrum board and Kanban board can look similar visually, they are based on very different principles.
To create a Scrum board, the Scrum team must first create sprints, assign points to user stories, and plan which stories go into which sprint. Then, the Scrum board visualizes the sprint, showing which stories are in plan mode or work mode. The Scrum board is reset between each sprint and is owned by one specific team.
A Kanban board has the same column-based layout as a Scrum board, but it requires no upfront planning. You can start working and moving through the flow of the Kanban board without having a structured plan. The Kanban board can be shared by multiple people and is persistent; you don’t need to reset the board. And, unlike the Scrum board, the Kanban board has a maximum number of stories allowed in each column at one time. This will continue to flow as long as the project continues, with new stories added and completed stories being reevaluated if needed.
When to Use Kanban
We recommend using Kanban if:
⦁ You need to add stories or change sprints on the fly
⦁ You don’t need iterations
⦁ Estimation isn’t necessary
⦁ You want the ability to release at any time
⦁ Continuous improvement is already emphasized
⦁ Your team doesn’t respond well to big changes
⦁ You want to improve delivery flow
⦁ The system needs to be easy to understand
Scrum can be less flexible than Kanban. The timing revolves around sprints, with each sprint lasting two to four weeks. In each sprint, the team has specific roles and follows specific ceremonies.
What Is Scrumban?
Scrumban combines the principles of Scrum and Kanban into a pull-based system. The team plans out the work that was established during initiation and continually grooms the backlog. The same Scrum meetings should take place, but the frequency can change depending on context and need. The most important part of Scrumban is making sure that work in progress limits (WIP limits) are followed.
Scrumban takes bits and pieces from both Scrum and Kanban. For example, it includes the defined roles, daily Scrum, and other meetings from Scrum. And from Kanban, it takes the Kanban board, continuous flow, and ability to add changes as needed to the board.
Scrumban can look more like Scrum on the technical level, but at the cultural level, it will more closely resemble Kanban. Instead of big changes all at once, Scrumban encourages incremental changes. If your team is looking to migrate from Scrum to Kanban, Scrumban can provide a gentle transition.
Which One Is Best? Kanban vs Scrum
When comparing Kanban versus Scrum, there is no definitive winner. The best framework depends on your project, team, and your goals. Because both Kanban and Scrum are flexible Agile methodologies, you could easily take principles from each and apply them as you see necessary.
It’s important to remember that true Scrum is a much bigger shift than Kanban. The team will have to learn about the ceremonies, the specific roles, and iterations. On the other hand, Kanban encourages incremental improvements. You can apply Kanban principles to any process you already have in place, even Scrum. Nothing needs to change significantly to get started with Kanban.
As a general rule of thumb, if your team or organization is really stuck and needs a big change, Scrum may be more appropriate. If you already have a process in place that you’re happy with, but want to implement some small changes, Kanban might be a better choice.
Comments
Post a Comment