Scrum Master Role | Scrum Master Tutorial | Simplilearn Video Lecture | Understand Project Management with Agile

[Music]
there are three distinct roles in scrum
the scrum master the product owner and
the development team the scrum master
assists both the development team and
the product owner the scrum master works
with the product owner to maximize
return on investment the scrum master
empowers the development team by
fostering creativity removing
impediments and coaching and mentoring
as appropriate the product owner is
responsible for project success by
defining the project vision requirements
and priorities the product owner has to
resist the temptation to manage the team
or add more important work after a
Sprint has begun the product owner has
to be willing to make the hard choices
during sprint planning the development
team is comprised of five to nine
members with a mix of roles and has the
autonomy to self organize and choose how
best to meet the goals of the product
owner and is responsible for the same a
scrum master is a skilled servant leader
a scrum master has very little formal
authority however he or she is expected
to assist the team achieve the intended
outcomes without interfering with the
team's autonomy the scrum master
facilitates the scrum ceremonies such as
sprint planning daily stand-ups sprint
review and sprint retrospective the
scrum master removes obstacles or
impediments faced by the team the scrum
master is also a process coach and
mentor the scrum master must not be a
line manager of the team the scrum
master is not to be a taskmaster either
the scrum master is not a technical or
design Authority nor is he or she a
decision-maker for the team throughout
the course of the project the scrum
master must not do anything to rob the
team of its empowerment and ability to
self organize
let's talk about the attributes of a
scrum master scrum masters need to
exhibit responsibility even though they
are not solely accountable for the
team's output they will consider it
their responsibility to remove anything
that impacts the team's productivity
they will try to enable the team to do
the best that it can they are humble
they will work in the background and let
the team take all the glory they will
use we statements and seldom use any I
statements they are able to set aside
their ego and shower all their attention
on the team they are by nature
collaborative they will encourage the
team to have conversations among each
other and with other stakeholders
outside the team they will nudge all the
right people into getting involved and
work together and trying to solve
problems they are committed to the team
cause even if being a scrum master is a
part-time task for them they will give
the highest priority to the team's needs
hence the scrum masters work allocation
especially if they are part-time needs
to take this into consideration they are
able to influence they are naturally
good communicators and able to convince
others to adopt different approaches
they apply various techniques to
mobilize organizational resources when
required walk the political tightrope
when required and in general do whatever
it takes to get the team the assistance
it needs they are knowledgeable it is
clear that as process coaches for the
team scrum masters need to be experts in
the method they may not be the technical
or domain experts however they are
knowledgeable enough to be able to have
productive conversations about the
project being done by the team tasks for
the scrum master the scrum master is a
crucial role and it is important for you
to be able to be clear about exactly how
the scrum master serves the team scrum
masters are
servant leaders this means that they put
the team before themselves and assist
the team for example they set up ensure
that the scrum ceremonies are
effectively carried out they ensure that
there is smooth flow of information
within and outside the team and that
there is a spirit of collaboration in
decision-making and problem-solving
scrum masters must make it their mission
to resolve issues that hinder team
progress it doesn't matter what the
nature of the issue is a scrum master
needs to mobilize the right resources
within the organization to resolve those
issues in a timely manner and escalate
promptly if that does not happen we need
to understand that in the short duration
of a sprint even a few hours of being
stuck can make the difference between a
successful and unsuccessful sprint scrum
masters protect the team they ensure
that the team is not disturbed or asked
to deviate from their commitments if
pressure mounts due to unreasonable
expectations they will step in and push
back on the team's behalf they will also
play the role of peacemaker when
conflict arises by encouraging the
parties to focus on the issue discuss
the issue with an open mind and resolve
the conflict
finally scrum masters are the process
coaches of the team they use their
understanding of agile methods and
sprung in particular to guide the team
through the do's and don'ts of scrum
they ensure that the team stays true to
the principles of agile development
scrum master roles scrum teams before we
discuss the role of a developer on a
scrum team let's talk about the
desirable characteristics of scrum teams
they should be small and nimble team
size should be no less than three and no
more than nine so that would be six plus
or minus three exceptions are possible
but uncommon the small attribute makes
the team nimble and in
proves productivity it avoids the
phenomenon Mike Kohn calls social
loafing and instead produces focus on
work the team size should be just large
enough that the team members are able to
produce and showcase a significant
increment of work at the end of each
sprint sprint after sprint
self-sufficient and cross-functional for
example if a team needs user interface
development skills database expertise
and service expertise all of those
skills must be present on the team
ideally team members are generalizing
specialists team members should not only
be an expert or a specialist at one
aspect of the development effort but
should also have enough skills and
knowledge to fill in in other roles as
necessary for example if you are a UI
developer you should be able to Don the
Hat of a services developer if needed if
a large team is to be split up into
smaller scrum teams scrum favors feature
teams over component teams autonomous
and self-organizing teams choose for
themselves how they are going to
organize and meet the goals of the
product owner no one gets to dictate to
the team how to get their work done the
team decides in collaboration with the
product owner the project direction and
the pros and cons of different
approaches let's talk about some key
decision points or factors to consider
when assembling scrum teams feature
teams over component teams the first
issue is whether it's best to align team
members based on features or components
scrum favors feature teams over
component teams for example it's best to
avoid putting all of the UI developers
together and all of the API or services
developers together
why because each feature or user story
will require both the UI and services
or API organizing based on components
will reduce the incentive to collaborate
the only reason component teams may be
justified would be if the components are
likely to be used by multiple other
teams assemble the right people it's
important to get the right mix of people
together for the team the right level of
technical and domain expertise teams
will naturally have both senior and
junior level developers this works
perfectly as there will be stuff that is
more appropriate for the junior
developers and stuff that is not also
one of the risks of a small team is that
the team may miss out on broader
perspective and dissenting views one way
to work around this is to deliberately
favour diversity in all aspects gender
ethnicity personality traits etc it may
take some time for the team to advance
through the storming stage of team
development and develop the trust
necessary to work effectively together
but it can be done once a team has been
formed it's best to preserve and assign
whole teams rather than individuals to
projects it's best to avoid assigning
team members to multiple projects at the
same time distributive team a
distributed team may be unavoidable
those based at the same geographical
location should be co-located in the
same team room and technology processes
and ground rules should be put in place
to overcome the disadvantages of all
team members not being co-located
plotting team size and productivity will
likely result in an s-curve you can see
here that a team can actually be too
small or too large remember the sweet
spot is six plus or minus three
hi there if you like this video
subscribe to the simple learn YouTube
channel and click here to watch similar
videos Turner DUP and get certified
click here