Before the Scrum guide version 2020,
the developers need to answer three
questions during the Daily Scrum.
But now in Scrum guide 2020 it's no
longer prescribed.
On one side I think this change gives
more flexibility for the developers in
running the Daily Scrum. But on the other
side, I also noticed that some people who
are new to Scrum found the ambiguities
in Scrum guide 2020 can be confusing.
So in today's video I will share with
you, practical tips on how to run the
Daily Scrum with Kanban. So stay tuned,
don't go anywhere, as I'll be back right
after this one.
[Music]
Hey ...
what's good this week awesome people?
Welcome back to my channel. For those of
you who are new to my channel, my name is
Joshua Partogi and I would like to
personally welcome you on board to our
community of passionate change makers.
Today's video is the continuation of my
video about Sprint Planning. If you
haven't watched that video, you can click
the link up here to watch that video
first. I'm also going to demonstrate how
the developers run the Daily Scrum with
Kanban using a tool called Kanbanize. I
have advised many Scrum teams to use
Kanbanize as it can generate flow
metrics that can be used for all of the
Scrum events. As a full disclosure to all
of you, Kanbanize is supporting today's
video. Keep in mind that kanban is not
part of Scrum, it is just one of the many
complementary practices out there that
you can use with Scrum. Please also keep
in mind that kanban is much more than
boards with columns and swimlanes. I will
not cover kanban in detail in today's
video. If you want to learn more about
how to use Scrum with kanban, you can
watch the video by clicking the link up
here. As written on Scrum guide version
2020, the Daily Scrum is an opportunity
for the developers to synchronize
information and to create tactics for
achieving the Sprint goal they have
agreed together with the whole Scrum
team during Sprint planning. Keep in mind
that only the developers who join the
Daily Scrum and the developers are not
only limited to software engineers. The
developers in the Scrum team are not
limited to only software engineers as
some people understood.
Everyone who has the skills to develop
the product for example designers, user
experience professionals, marketing
professionals, system architects, analysts,
test engineers, technical writers are
also considered as the developers in the
Scrum team. They all attend the daily
Scrum. In your context, the developers in
the Scrum team may consist of different
composition of skill sets, depending on
the product being developed by the
developers. If you're still unsure who
are referred as the developers in the
Scrum team according to Scrum guide 2020,
you can click the link up here to watch
the video I've already made about the
developers in the Scrum team.
Daily Scrum is not about reporting the
status of the work done by each
developer.
Daily Scrum is about creating daily
tactics for achieving the Sprint goal.
It's a big difference. If the developers
are developing products to solve a
complex problem as defined in Scrum
guide, most likely they need to create
tactics daily. To give you a little bit
of context, here is an example of an
outcome driven Sprint goal the developers
will inspect during the Daily Scrum
until the end of the Sprint.
Just like what you have already seen on
my Sprint planning video.
During the Daily Scrum, the developers
can replan the initial plan they have made
during Sprint planning but the Sprint
goal remains sacrosanct until the end of
the Sprint.
Scrum is a goal-driven framework. When
the Scrum team uses kanban, during the
Daily Scrum the developers will scan
through their kanban board from the
right towards the left.
But it doesn't just stop at scanning the
kanban board. As the Daily Scrum focuses
on the Sprint goal, the developers will
also ask each other which product
backlog items they should process
today before the next Daily Scrum so they
can achieve the Sprint goal and which
product backlog items are currently
blocking them from achieving the Sprint
goal. When answering the two questions
that I have just mentioned, the developer
should emphasize on the items on the
kanban board and the Sprint goal rather
than the individual developers doing the
work.
It's a big difference. When the Scrum
team is using kanban, during the daily
Scrum the developers look at the aging
work in process (WiP) chart and also the items
with cycle time that have already
exceeded or will likely exceed the
service level expectation or SLE that
they have agreed on.
The aging work in process chart is built
in Kanbanize. Kanban is a pull system
rather than a push system. Whenever the
developers self manage to pull any
product backlog items on their kanban
board, they must not violate their work
in process or WIP limit. When the
developers run the Daily Scrum according
to the approach that I have just shared
with you, from my personal experience the
Daily Scrum should not take more than 15
minutes. One last thing the developers
need to do to ensure that Daily Scrum
does not take more than 15 minutes is to
solve any problems they found right
after the Daily Scrum not during the
Daily Scrum.
After the Daily Scrum, some developers
may be collaborating with one another to
solve the problem or to remove the
blockers. It requires openness and
humility from the developers to
collaborate and to learn something new
with the other team members who have
different skills and even different job
titles to them. For example, after the
Daily Scrum someone with business
analysis skill may pair with someone who
has this engineering skill to test the
increment or to write the test
automation scripts together.
People with software engineering skills
and those who have design and user
experience skills, together may create an
experiment to validate a hypothesis.
After the Daily Scrum, the developers may
also need to talk to the Product Owner
about reducing the scope of work or the
level of fidelity of the work. The
developers must always keep the Sprint goal
in mind whenever negotiating with the
Product Owner is needed. As I have
mentioned on my Sprint planning video,
the Scrum team has succeeded when they
meet the Sprint goal even if they
deliver less amount of items than what
they have planned during Sprint planning.
Keep that in mind folks.
So to wrap this up, the developer should
just focus on three things during the
Daily Scrum, they should focus on the
Sprint goal, focus on creating tactics and
focus on optimizing the flow of value
delivery. They can use kanban as a
strategy for optimizing flow. If you're a
Scrum Master, empower the developers to
self-manage and do their magic.
Thank you folks for watching today's
video. I hope today's video gives you
some ideas on how to run an effective
Daily Scrum with kanban. As i mentioned
earlier today's video is supported by
Kanbanize. If you would like to try
Kanbanize in your Scrum team and
subscribe to it, you can use the referral
link down here.
Because transparency is one of the three
pillars of Scrum, as a full
disclosure, I will get a commission every
time any of you subscribe to Kanbanize
from that referral link. Every commission
I get will help grow this channel. Thank
you folks for your continuous support of
this channel, your support of this
channel can enable more Scrum teams to
do professional Scrum. That is all for
today folks, don't forget to smash that
like button down below and also to
subscribe to my channel because I will
upload my videos in the future that can
help improve your Scrum team's
effectiveness and also your organization
state of agility. And for those of you
who aspire to be an awesome Scrum Master,
you can also subscribe to my podcast
either on spotify, google podcast or
apple podcast. You can search my podcast
name using the keywords "Think and act
like a Scrum master".
And while you wait for my next youtube
video or my next podcast episode you can
click the thumbnails here ...
to watch the other videos currently
available on this channel. Until then
don't forget to stay safe and stay
awesome.
Bye now. Bye.