Hey what's up awesome people! Welcome back to my channel. Joshua Partogi
here. Today I'm in the city of Bandung, Indonesia and as some of you already
requested in today's video I'm going to be talking about how to use Scrum with
Kanban. This is going to be a long video so if it's possible stay until the end
of this video so that you don't miss any important information from this video. If
you're interested to know how to use Scrum with Kanban,
don't go anywhere. Stay tuned.
In today's video the resource that I'm gonna be using to talk about how to use
Scrum with Kanban is the Kanban guide for Scrum teams from Scrum.org.
Check the link down here and make sure you read it after you watch today's
video. A lot of videos on YouTube that compare Scrum and Kanban describes
Kanban as boards with sticky notes and swimlanes while Scrum is a framework
that has many meetings. Now this is quite unfortunate because Scrum and Kanban is
more than just that. According to Scrum Guide, Scrum is a
framework within which people can address complex adaptive problems while
productively and creatively delivering products of the highest possible value.
The keywords that we have to keep in mind here are framework, complex problems,
products and value. According to Kanban guide for Scrum teams, Kanban is a
strategy for optimizing the flow of value through a process that uses a
visual work in process limited pull system. The keywords that we have to keep
in mind here are: strategy, flow, value, process, visual, limited work in progress
and also pull system. So a framework and a strategy does not conflict with each
other. In fact it's not even comparable, they complement each other.
Kanban gives you the process while Scrum is just a framework without any process
in it. There are a lot of aspects that's beneficial that's provided by Scrum
out-of-the-box but not provided out of the box by Kanban. So even teams that
already use Kanban will incrementally add these aspects into their process
to increase their current agility. The same things
also for Scrum teams will add the aspects that's provided by Kanban
out-of-the-box but not provided by Scrum. So let's look at how they differ and how
they complement each other. Let's talk about what are the things that lower
case k Kanban does not talk about and the things that Scrum does not talk
about so that we know how they complement each other. Let's drill down
what are the things that lower case k Kanban does not talked about. First of all
lower case k Kanban does not talk about coaching and servant leadership. Yes
Toyota Production System (TPS) which is where Kanban originated from emphasizes
coaching and servant leadership but the lower case k Kanban
does not. In Scrum, coaching and servant leadership is the Scrum Master
responsibilities. Some of you already know I'm a big fan of coaching and
servant leadership. I personally think it is a humane way to lead people in the
21st century. Secondly lowercase K kanban do not have built-in feedback loops like
the Sprint and Daily Scrum. Feedback loops are important in innovative
complex work. Every event in the Sprint increases transparency and provides
opportunity to inspect and adapt. Many awesome teams that initially only use
Kanban I have coached add feedback loops that are similar to a Sprint and Daily
Scrum. Thirdly, lowercase K Kanban does not talk about goal like the Sprint goal
in Scrum. Without a goal the team will solely focus on output rather than
outcome and will make them look like a feature factory. In creative work like
product development, the business outcome is more important than the number of
outputs delivered. The Sprint planning is an opportunity for the whole team to
sync up on the Sprint goal and to work as a team rather than as a bunch of feature
factory workers. The Daily Scrum itself is an opportunity for the team to look
at their current progress towards achieving the Sprint goal. Fourthly,
lowercase K Kanban does not talk about the Definition of Done or the definition
of potentially releasable product explicitly. As Scrum is a framework for
product development, the Definition of Done creates transparency about how the
overall quality of the product should be. Awesome teams that initially only use
Kanban will add Definition of Done to their current process. Now let's drill down
what Scrum does not talk about and how Kanban can leverage Scrum. Firstly Scrum
does not talk about any charts and metrics. Velocity and burn down chart is
actually not part of Scrum as it is not defined in Scrum guide. As Scrum is just a
framework, Scrum teams can use Kanban charts and metrics to help them improve
their current agility. Secondly, Scrum does not prescribe visualizing how the
product backlog items flow from one end to another end. Visualization of how the
work flows is the core of Kanban which is helpful
for Scrum teams to improve their agility. Thirdly, Scrum does not talk about
Service Level Expectation (SLE) that is helpful for teams to choose, either
during Sprint Planning or Daily Scrum, which Product Backlog items they should
be working on next. Now after we talk about the differences between the two
and how they complement each other, now let's talk about the similarities
between Scrum and Kanban. Both Scrum and Kanban talk about transparency even
though it is at a different level. Scrum requires the three main artifacts that
is the Product Backlog, the Sprint Backlog and the increment to be made
transparent while Kanban requires the team to visualize the workflow. Both Scrum
and Kanban talk about continuous improvement. Scrum explicitly has a built
in event for discussing improvements called the Sprint retrospectives. Even
though improvements can be discussed at any point in time within the Sprint
without having to wait until Sprint retrospective but having retrospectives
creates a regular rhythm for focusing about improvements. Kanban encourages the
team to continuously improve their workflow using the flow metrics. Both
Scrum and Kanban talk about self-organizing teams even though in
Kanban self-organizing teams is not mentioned explicitly but in Kanban the
work is pulled by the team member rather than assign or pushed by a manager or
anyone else outside of the team. Lastly, both Scrum and Kanban talk about
limiting the work in process during Sprint Planning, the Scrum team makes a
forecast and limits the work for the Sprint implicitly. Awesome Scrum teams
also limit the work they will do for the day during Daily Scrum. In Kanban, teams
limit the work in process and visualize it explicitly on their Kanban board.
Teams are using Kanban when they do the following four Kanban practices, if
they're not doing all of it they're not really using Kanban. Firstly, teams need
to visualize how they work flows from one end to another end. Secondly, teams
need to limit the work that is currently in process. Thirdly, teams need to
actively manage the work in process so that optimal flow can be achieved.
And lastly, teams need to deliberately inspect and adapt their definition of
workflow. That means if the team Kanban workflow did not change compared to the
one they had a year ago, they're not really using Kanban. Now, just having a
board with sticky notes and swimlanes it's just the first aspects of Kanban. If
the team is not doing the other three practices of Kanban they're not really
using Kanban, they just have a task board. Besides the four Kanban practices teams
using Kanban also need to track the following four Kanban metrics. The first
metric they need to track is work-in-process,
which is the number of work that has started but not yet finished. The second
metric they need to track is cycle time, which is how long it takes when a work
item starts until it is finished. The unit is in days.
Bear in mind that cycle time is a lagging indicator and not a leading
indicator, which means you only know the cycle time of a work item when that work
item is finished the third metric they need to track is work item age, which is
how long it is when a work item starts at until the current time. As long as the
item is not yet finished the age increases everyday. Work item age is a leading
indicator, which means you know the age of every work item at any point of time. The
last metric they need to track is throughput, which is the number of work
items finished per unit in time. That means we can look at daily throughput,
weekly throughput, and even per Sprint throughput. Unlike velocity, throughput
does not consider the size of every work item. If teams using Kanban are not
tracking these four metrics, they're not really using Kanban. Besides the four
metrics, Kanban also has Service Level Expectation or SLE.
According to Kanban guide for scrum teams the SLE itself has two parts: a
period of elapsed days and a probability associated with that period. The SLE
should be based on the Scrum teams historical cycle time. And once
calculated, the team should make it transparent for everybody. Now that we
have talked about all of the Kanban practices and all of the Kanban metrics
that teams need to track, now let's talk about how Scrum and Kanban can be used
together. During Sprint Planning besides inspecting the Product Backlog, the
Definition of Done, the previous Sprint retrospective commitment and the Sprint
goal before gauging the work for the Sprint the Scrum team also inspect their
throughput metrics from the previous Sprints. When scrum teams are using Kanban
the focus should not be about matching the current Sprint throughput with the
previous Sprints throughput. As Scrum is a goal driven framework achieving the
Sprint goal is more important than matching the previous Sprint's
throughput. Now whenever I said that the Scrum teams need to inspect the
Definition of Done every Sprint planning they thought that I'm referring to the
acceptance criteria. The acceptance criteria and the Definition of "Done" is
really different. I've already made a video on the Definition of "Done", if you
haven't already watched it click the link up here to watch the video. During
Daily Scrum when the team plan what Sprint backlog items they want to work
on before their next Daily Scrum besides inspecting the Sprint goal, the
development team also inspect the work item age for each Sprint backlog items
that is on their Kanban board and see which items that is blocked towards
meeting the Sprint goal and will likely violate their Service Level Expectation.
During Sprint review besides inspecting how the increment has achieved the
Sprint goal, the whole scrum team along with the stakeholders can make a
delivery forecast using the throughput and also the cycle time metric. They can
also inspect the age of Product Backlog items that's currently in the Product
Backlog and throw away any items that's no longer relevant. As I mentioned on my
previous video the organization mindset during Sprint review should still be
about outcome over output. The throughput metrics that is used during
Sprint review shouldn't be used to push the team to work as hard as possible to
deliver as many output as possible but it should be used to forecast how much
outcome that the organization will likely get in the future. Now I've
already made a video on how to create an outcome driven Sprint goal, if you
haven't already watched the video click the link up here to watch the video.
During retrospectives, the Scrum team can talk about improvements using cycle time
and throughput metric. The conversation around this usually leads to
improvements like Product backlog refinement techniques or adding DevOps
or eXtreme Programming (XP) practices like automation or improving their current
User eXperience (UX) techniques or even changing the work in process (WIP) limit for
the next Sprint, etc. So that is all from me today folks. I've had enough of
Bandung for today. It's time for me to go back to Perth. If you found today's video
insightful as usual don't forget to smash the like button and share today's
video and don't forget to subscribe to my channel so that you won't miss any of
my video in the future. I hope you found some insights on how to improve your
agility using Scrum and Kanban. See you until my next video.