If you've found this video, the chances are that you've just done a search for the difference
between Scrum and kanban,
you've come to the right place.
Not only do I have a great video for you,
I also have a cheat sheet for you to download.
Hi this is Gary Straughan
Welcome to Development That Pays
Scum and Kanban are perhaps the best known of a number of Agile software development
methodologies
Let's break that down.
Software Development looks like this:
The Product Owner decides what to build
The Development Team builds it
and Customers use it, experience it, benefit from it in some way
What makes software development AGILE
is that VALUE is delivered to the customer in small increments
And, IMPORTANTLY, feedback is gathered from customers and fed back into the process.
It's the Product Owner's job to take input from customers
- and from stakeholders -
and organise it into a PRIORITISIED list of features and User Stories.
This list is known as the Product Backlog.
What happens between the Product Backlog and the Customer
is what distinguishes Scrum from Kanban.
As we'll see, each has its own routines and rituals
it's this person's job to help the Product owner and Development Team to adopt and maintain
good habits.
In Scum, the role is known as the Scrum Master.
In Kanban, the role is known as the Agile Coach.
Something that Scrum and Kanban have in common is that both are PULL systems.
Without getting into two much detail, the pull system ensure that work gets from Product
Backlog to Customer in the shortest possible time.
The pull system also helps to uncover bottlenecks in the process
Which helps to ensure that work gets from Product Backlog to the Customer
in the shortest possible time!
As you'll see in a moment, Scum and Kanban implement the pull system in two strikingly
different ways
Scrum teams work in a series of SPRINTS, most commonly two weeks in length.
Each Sprint it proceeded by a "Sprint Planning Meeting"
run by the Scrum Master and attended by the Product Owner and the Development Team
Together they select high priority items from the product backlog that the Development Team
believe it can commit to delivering in a single Sprint.
This is the "pull" I was talking about earlier.
The selected items are known as the SPRINT BACKLOG.
For the next two weeks, the Development Team focuses on working through the items in the
Sprint Backlog.
And ONLY those items in the Sprint Backlog:
in all but the most exceptional circumstances,
any new requirements that arise have to wait for the following Sprint.
It's common practice for Scum teams to use a board to track the progress of the work.
It's called a Scrum Board... or an Agile Board...
or even (slightly confusingly) a Kanban Board.
Each day during the Sprint there is a Scum Meeting:
it's a stand up meeting where the team takes a maximum of 15 minutes to discuss progress
and identify any "blockers".
At the end of the sprint, the work completed during the sprint is packaged for release
Any incomplete items are returned to the Product Backlog
The Sprint ends with two rituals:
The Sprint Review, which is a demonstration of new functionality to Stakeholders.
The Sprint Retrospective, which is an examination of what went well, what went badly and what
could be improved.
The aim of the Retrospective is to ensure that the next sprint is more efficient and
effective than the last.
And that's Scrum
Kanban does a few things differently.
There's no two-week sprint: Kanban is a continuous process.
There's no Sprint Backlog.
The "pull" system in Kanban happens in a different way, via Work In Progress limits.
Each column on the Kanban board has a Work in Progress limit
related to the team's capacity.
For example a team with two developers would set a limit between two and four items.
The lower the better.
Let's see the pull system in action.
When testing of a particular feature is complete, the corresponding ticket moves to the "Done"
column
The empty column is a signal to the previous column to send another ticket.
That's the "pull"
And when the in "Build" column is almost empty
is a signal to the team to select another high priority item from the Product Backlog.
That's the "pull" again.
Like Scrum, Kanban has :
Daily Stand-up
Demo for stakeholders
Retrospective
So now you know the key differences between Scrum and Kanban.
Two important things to say at this point:
Neither Scrum nor Kanban are as prescriptive as I may have made them appear.
High performing teams discover what works for them
and flex the system appropriately.
I've put together a CHEAT SHEET for you
that covers everything that we're talked about today
plus some additional notes that I think you will find useful.
You can grab your copy from my blog
via a link that you'll find somewhere around this video.
If you liked this video, please click to LIKE
SHARE it with your colleagues
and be sure to SUBSCRIBE for a brand new episode every Wednesday.
Thanks for watching and I look forward to seeing you again soon.