Scrum vs Kanban
- 2. Blackvard Management Consultants
www.blackvard.comCopyright © Blackvard Management Consulting – All rights reserved
Erin Lett is the Operations Manager for Blackvard
Management Consulting. She holds a Bachelor’s Degree
from Stetson University in Communications and has been
working in the SAP, eLearning, and Software Development
industries for the past 6 years.
For further information please visit:
www.blackvard.com
elett@blackvard.com
Copyright © Blackvard Management Consulting- All rights reserved www.blackvard.com
Your Host
Erin Lett
- 3. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
Agenda
What Will Be Covered:
1. Waterfall Development
2. SCRUM In A Nutshell
3. KANBAN In A Nutshell
4. SCRUM vs KANBAN
5. Advantages Of Both
6. Which Do We Use?
7. Q&A Session
- 4. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
Waterfall Development is a sequential design used in software development.
Progress is viewed as steadily flowing downward through phases
Originated in manufacturing & construction industries
Waterfall Development
Requirements
Design
Implementation
Verification
Maintenance
Product Requirements Document
Software Architecture
Software
- 5. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
One phase must be completed before moving on to the next phase.
Rarely re-visit a phase once it has been completed
High risk – accuracy is critical the first time around
Changes after the fact are often not possible
More costly & less efficient than Agile approaches
Waterfall Development
Value is realized at end of project (deployment).
End of project testing leaves room for unresolved issues
Stakeholder requirements & needs could have changed
Heavily reliant on planning & project managers
SCRUM & KANBAN came about due to skepticism in regards
to how to predict w/ waterfall across long periods of time.
- 6. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
SCRUM In A Nutshell
SCRUM is an Agile framework used for completing complex projects.
Originally designed for software development projects.
Works successfully for any complex/innovative project
Emphasizes team collaboration & provides a minimal set of rules.
Allows for requirements to be prioritized & changed.
Gives team the power to commit to requirements per capability.
Product Backlog
Sprint Backlog
Sprint
2 – 4 Weeks
24 Hours Deliverables
- 7. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
SCRUM In A Nutshell
SCRUM divides organization into small, cross-
functional & self-organizing teams.
Divide tasks into a list of small & concrete deliverables.
Arrange list by priority & estimate the relative effort for each item.
Divide time into short fixed-length iterations.
Potentially shippable code demonstrated after each iteration.
Optimize the release plan.
Update priorities; collaborating w/ customer or shareholders, based on
insight gained by inspecting the release after each iteration
Optimize the process via feedback.
Hold retrospect after each iteration
Jan May
- 8. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
KANBAN In A Nutshell
KANBAN is a technique for managing software development
processes in a highly efficient way.
Toyota’s ‘just-in-time” (JIT) production system
Limit work in progress (WIP)
Limit how much unfinished work is in progress & reduce
time it takes an item to travel through KANBAN system
Focus on Flow
Uses WIP limits & team-driven policies
Continuously Improve
Tracks effectiveness, quality, throughput, lead times, etc.
Visualize the workflow
Divide tasks into pieces, write items down & put on task board
Use columns to illustrate where each task is in workflow
- 9. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
SCRUM & KANBAN As Process Tools
SCRUM & KANBAN are both process tools.
Used to accomplish a task or purpose
SCRUM – more prescriptive (more rules to follow)
KANBAN – more adaptive (fewer rules to follow)
Which is better, SCRUM or KANBAN?
The answer truly depends on your context
Knife vs fork vs chopstick
Neither one is perfect or complete.
One alone won’t depict every task/project requirement
Provide certain constraints/guidelines
Value found in tools that limit options
- 10. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
Roles of SCRUM & KANBAN
Product Owner defines & communicates product requirements.
Represents the stakeholders & voice of customer
Prioritizes & empathizes w/ team members & stakeholders
Development Team delivers Potentially Shippable Increments (PSIs).
3 – 9 individuals w/ cross-functional skills
Analyze/design/develop/test/document
SCRUM Master facilitates the SCRUM.
Removes product & deliverables impediments
Buffer between team & distractions; enforces SCRUM rules
KANBAN does not prescribe roles.
If desired, roles can be included
When adding roles, ensure value & lack of conflict with other process elements
- 11. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
SCRUM vs KANBAN: Fixed Timeboxes
SCRUM - Narrows predictions to timeboxed iterations.
Choose length, keep iterations the same to establish cadence
Fixed timeboxes – 2-4 weeks in length; bookended by sprint meetings
KANBAN – Timeboxes are not prescribed.
No incremental planning (sprint meetings, etc.)
Timeboxes & increments can be included if desired
Beginning of iteration
Iteration plan is created
During iteration
Team focuses on completing task items
End of iteration
Team demonstrates working code (potentially shippable)
Retrospective – discuss & improve process
- 12. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
SCRUM vs KANBAN: Tasks & Estimates
SCRUM - Team determines Tasking & Estimating during planning meetings.
How much work they can complete in a timebox to deliver an increment
KANBAN - There are no Task Estimates required.
The team simply takes the next item and begins working on it
- 13. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
SCRUM vs KANBAN: Tracking
SCRUM – Tracks Velocity
How much work tends to get done over time from increment to
increment; timebox to timebox
Intended to help teams get better at their commitment to what
they can achieve within a timebox
KANBAN – Tracks Flow
Does not track velocity, but rather holds the notion of tracking:
Queues: Waiting for service to begin on an item
WIP (Work In Progress): How many things are currently being worked on
Cycle Time: The moment work began on an item & how long it takes to be completely done
SCRUM & KANBAN limit Work in Progress (WIP) in different ways.
Cycle Time
- 14. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
SCRUM vs KANBAN: Process Owners
SCRUM – SCRUM Master owns process
Notion of how process works is given to the Scrum Master
to help inform the team of details of defined process
KANBAN – Team owns process
No fixed defined process
Team takes whatever process is at hand &
gives measurements:
Queues/ WIP/ Cycle Times
Team determines how to continually
improve the process
Recipe to
improve
capability
- 15. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
Advantages of SCRUM vs KANBAN
Advantages of SCRUM
Transparency
Improved credibility w/ clients
High product quality
Product stability
Team reaches sustainable pace
Allows client to change priorities & requirements
Advantages of KANBAN
Flexibility
Focus on continuous delivery
Increased productivity & quality
Increased efficiency
Team has ability to focus
Reduction of wasted work & time
- 16. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
SCRUM or KANBAN?
Should we use SCRUM or KANBAN?
Ask which aspects of SCRUM & KANBAN can be used to
effectively develop products & services.
Decision should be made by development & product teams.
Recently, combinations of both frameworks & best practices have been used.
Easy & worthwhile for teams to explore both options.
- 17. Copyright © Blackvard Management Consulting – All rights reserved www.blackvard.com
Have Additional Questions?
Want To Set Up A Consultation?
Email: info@blackvard.com
Questions & Answers
Editor's Notes
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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!
- 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”) .
- 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.
- 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
- 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.
- 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-
- 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.