hello everybody and welcome to today's presentation what is scrum an introduction

to the
scrum framework brought to you by scrum org before we get started I'd like to take
care of a
couple of housekeeping items first off I'd like to make sure you can all hear me okay
so if you would just send me a
quick update in the chat window to let me know you can hear me great if you
have any questions for our presenter today please post those into the questions
panel so we can get to them
after the presentation if you experience any technical difficulties like the audio
dropping out or the screen sharing
not displaying properly please post a message in the chat panel and I will work with
you to resolve those issues
lastly on the housekeeping list we are recording today's presentation and we'll be
making it available shortly after
today's event concludes now that we're through the housekeeping items I'd like to
introduce you to our presenter Eric
neighbor is vice president of marketing and operations at scrum org eric is
co-author of UML for database design and UML for mere mortals Eric is currently
responsible for all aspects of marketing and operations for scrum org now I'd
like to do a quick sound check for Eric so Eric if you would like to say hello to our
audience and audience please let
me know if you can hear Eric by posting a message in the chat panel good morning
good afternoon good evening everybody
thanks for joining today great well
without further ado I'm going to turn things over to Eric to begin the presentation Eric
great thank you very
much and hi everybody it's always it's always weird hearing yourself introduced um
just thought that as you heard I run
marketing in operations for scrum org I've been in software development in software
delivery for more than 25 years
now helping teams and organizations build software based products and really
helping helping to put process these in place and so on so that's enough about
me but a little bit about scrum do it very briefly our mission is about improving the
professional software delivery and really helping teams improve how they deliver
software scrum can you use more
probably than that and I'll talk about that in a minute but but that's our main focus in
where we focus something really
interesting that I find is as surveys have been done and lots of things has happened
that there's an estimate of
about 90% of agile teams which equals into the tens of millions of people every day
use scrum in some way scrum
dog we have over 200 trainers around the world we've taught over a hundred
thousand students were global we've got
trainers in almost every continent and we provide certifications as well as
training and thought leadership a lot of new ideas new concepts the overlooking
of scrum itself and so on come out of scrum dot org we were founded by Ken
Shui burr the co-creator of scrum and we continue and Ken continues to drive scrum
forward so a little bit about what
we'll hear today why scrum in what is it the scrum values which really really
important to upholding how teams work and work together we'll go through the
different aspects of the scrum framework the roles the artifacts the events but I also
want to touch on a few other things
and then we'll have time for Q&A at the end so before that I wanted to take a
quick survey and just understand do you use scrum how do you as teams use it so
real quick if you can provide us with that information that would be great
you so I when I when I talk to in work with
teams generally we get a very wide variety of experience and then this will
just help me a little bit on to understand that
do we have results we got about 81% in will give a few more moments for some
last minute answers and we'll close that up
we show those results all right area looks like we have 46 percent said yes
19 percent said no and 35 percent said somewhat it's about probably a little
higher than I expected on the F but everything else pretty pretty much where
I expected to some what's always an interesting one because as we see in
even in that 90 percent number people say oh we do a daily scrum so we're doing
scrum well no you're not doing
from your you're doing a piece of it that's that that's somewhat let's go back to the
presentation and we'll keep
going here so that that is helpful though so I'm for those of you who are not familiar
a little bit of history
where did scrum come out of it came out of understanding that waterfall just it
was a standard but there were issues gathering all the requirements up front and
trying to deliver 18 to 24 months
later we were delivering the wrong things the wrong products and in the wrong
features to market not satisfying
our customers I worked on a project here in the US with the IRS and that that
project I met with them every year I was doing a little bit of helping and guiding with
them and I met with them
every six months for about two years a few years later they delivered the wrong
thing they were still not complete they were delivering the wrong features and their
own capabilities and what we found
out was they gathered all these requirements and as they went through the process
of delivering on those
requirements the world had changed and they were delivering the wrong thing so
we needed to invent something different we needed to do something different so in
1995 Kennish waiver and Jeff
Sutherland the co-creators of scrum got together at Upsala which is a conference
around object-orientation and presented
their paper on scrum and talking about how do we deliver small things small
increments in short periods of time to deliver more value and learn from that
and keep going and what came out of that as a framework for developing and
sustaining these complex products
so where does crumb fit if we have a very predictive process if everything happens
the same way every time do we
really need scrum probably not we don't want to be changing our process every day
or every month when we're building
say in this in this example and engine but if we're building things applications in our
phone and those sort
of things that have to have constant and frequent inspection and an adaption
constant changing we need to completely
learn something that empirical this is where scrum can be very well
applied in those complex worlds so the scrum comes from the body of
knowledge is from is written by its creators Ken and Jeff new version came out in
November of 2017 so last year and
it's available I had thought that was on the link was on here at def available at
scrum guide dot org or also on scrum orgs website which links over to scrum
guides org this is the body of knowledge of scrum there is only one scrum as defined
by those creators of it and it's
translated in over 40 languages as well for those of you who are not native English
speakers so scrum is for complex
work not just software research and identity identifying markets hardware
government's process marketing as well it's all about releasing products and
enhancing frequently it may be galley it may be monthly it's about getting
those frequent products to market and its really to support the entire product
through its overall lifecycle so as
we're thinking about what we do and how we work we're looking at scrum as a
framework and scrum you add practices to its crumbs not a methodology that's a
question that comes up or a comment that
comes up quite often so I use the scrum methodology with scrum is not a
methodology a methodology tells you
exactly how you're going to work the exact process you're going to follow
and doesn't often change scrum is an empirical process allowing me to
consistently and continuously inspect and adapt how we work bring on practices like
XP like test-driven development and
so on to improve my process team by team and group by group because my team
works
differently than your team and if I try to bring in this big process place it down say
this is how we're all going to
work we're going to find a lot of difficulties with that so when we look
at scrum it really is about empiricism it's about transparency everybody knows
what's going on how we're working we
have transparency into the work and into the teams the teams are constantly
inspecting and adapting looking at how we work how we do the things that we're
doing and we change based on that
learning based on what we know based on what we do so we're constantly
inspecting and
adapting that that Perriman will talk about some of some of the events shortly but
the daily scrum the daily scrum is
not a status meeting it's about constant inspection what are we doing how are we
doing it and what do we need to change to get there and that's what our entire
process that that process that involves
out of the scrum will framework provides so scrum values I put this in because I
feel like this is very very important for everybody to understand I've worked on
multiple scrum teams and
when the scrum teams don't adhere to these values we start to get into disarray we
start to get into
disagreement and we start to really not work together as a team the team members
needs need to have courage they need to have courage to deal with the right things
the right problems bring up
activities bring up problems bring up issues bring up concerns as they come up and
if they don't have that and if
they're not empowered so it's also very important that they're empowered to have
that courage if they feel like
executives are looking down on them and every time something comes up they're
going to get beaten down or you just
took that courage away they need to focus on the sprinkle and the goals of that
sprint the goals of the scrum team
they need the commitment at a personal level to deliver and work with the scrum
team I respect each member and open this to share that information whether it's
with stakeholders or other team members
but I thought this was a really good little cartoon to show how how sometimes
that courage doesn't think this as you can see you know how's your project
coming on oh it's streaming it's a failure it's going to fail well now all of a sudden
that's that now on something
that comes in ah how's it coming everything's going great there's no courage there
we don't have the ability
to inspect in the depth we're just placating management and what happens we don't
deliver we don't
deliver we don't deliver we deliver the wrong things everybody's surprised at the end
in scrum there should never be a surprise
ken always talks about the fact that if you're trying to hide things scrum is
not a good place to be we're trying to hide the way we work if
we have a bunch of holes that we're trying to plug scrum is going to identify those
because you have that
transparency you have that constant inspection and adaption it's all driving
toward a common goal so let's get into scrum in the heart of scrum scrum has a
set of roles the three that you see there instead of artifacts again the three that you
see there in a set of
events this is scrum it's a simple framework again according Ken I'll say it's simple
to understand in very very difficult to master because we're constantly learning
we're constantly inspecting we're constantly adapting but as you can see here it is a
fairly simple framework and
this is just the view of a single sprint so we're looking at one sprint how does
that work from sprint planning all the way through to delivering it into my
retrospective so let's go through each
one of those and starting with the roles so there are three roles in scrum only three
we've got a product owner and
there's one we've got a scrum master and there's one and we've got a development
team members that make up that development team this is what makes up the
scrum team one product owner one
scrum master and a set of development team members that deliver
as a scrum team so the product under their job and their role is to maximize
the value of the product backlog and what they're delivering development team
getting things done and the scrum master making sure that
the team understands how they're working making sure the team is working well
together and in removing any impediments
that the team may have and that is the scrum team fairly simple so a little bit
deeper into the roles in looking at those the product owner what is the
product owners role the product owners role is to understand and work with
different stakeholders whether their customers executives other people internal or
external customers by the
way it doesn't always have to be an external product the internal customers are just
as important or users as you
may call them as external depending on the product that you're building and
delivering a product owner is ultimately
responsible and accountable for that product does that mean they
work alone no you may have a big product they may not be the subject matter
expert in every little piece they can work with others but they're the ones that are
ultimately responsible and
accountable for that so they may work with product managers who are on that
scrum team or business analysts on that
scrum team they're getting their information those from different stakeholders
throughout the process but
they are the ultimate owner of the product backlog of what that product
will be as that owner and that's really important on what we find is product by
committee generally doesn't work we need somebody who has an ultimate
responsibility it doesn't mean that they're not working with those others but if we
start getting to everybody's
features coming in and my opinion in your opinion now we get conflicting products
we get products that don't look
alike we get products that the highest priority features might be the person who
yelled the loudest and not
necessarily the right things for the users at the end at the end of the day the product
owners responsibility is to
deliver value back out value very important often I hear people
talk about scrum and they talk about velocity and hyper velocity and
delivering faster and so on garbage in is garbage out if we deliver the wrong
thing it doesn't matter if I deliver the wrong thing faster slow it's still the wrong thing
so we need to not just focus
on speed we need to focus on quality and value in delivering the right thing now
scrum because of its short increments
Sprint's allows me to understand very quickly if I'm delivering the right thing of the
wrong thing but it's not
just about the speed it really is about our ability to deliver and deliver the
right thing the scrum the scrum master they promote scrum has defined in the
scrum guide
because there is only one scrum one scrum guide they help everybody understand it
and they also provide
guidance do you think that scrum master you'll hear quite often the servant
leader they help lead the team but they help the team lead itself so the scrum
masters role is not there to tell everybody what to do it's to help
everybody figure out what the right things are to do if to help guide that team that
scrum team or as they're
working to self organize as they're working to do the right things to help
cut any impediments if there are dependencies on other teams or on other
parts of the organization if things aren't working well together help guide them
they're not the project manager
they're not the manager of the team they are really there to help support the
team and support that organization it's a very very difficult role and there's a
development team or the development team members really because the roles are
those members each individual is on that
team they create that product increment they operate in a series of sprints that
we'll talk about in a moment they help organize the work and they work with the
product owner they work
with with with with the product owner and their stakeholders to understand and
make sure they're building out the right
thing at the end of the day they're self-organized team that has
everything that they need to deliver that product
whether they have people from operations on that scrum team or they can deliver
and do operations themselves but they have all the expertise within that scrum
team to be able to deliver the right product to market the artifacts
so there are three artifacts for every four fruits in the scrum framework we've
got a product backlog that's where we hold the requirements for the product this is
managed as we just talked about
by the product owner we've got the Sprint backlog this is where the
activities that we're going to do within the Sprint are held and we pull
information from that product backlog into the Sprint backlog and then we have the
increment potentially release so it
doesn't say we have to release every sprint but it has to be potentially releasable it
has to be a full working
piece of product and that increment as well can be made up of lots of
releases we may have released every day or every hour throughout that sprint which
makes up that full increment that
was delivered during that sprint there's nowhere in scrum that says I cannot release
more than one time per sprint I
can release as often as make sense and as allowed by the product owner so
the product backlog sovalo product backlog items may include things like
feature definition constraints behaviors use cases bug defects and so on both
functional as well as non-functional requirements there's nowhere in scrum that says
this is how I will define the
backlog items it doesn't say I must use user stories I must use use cases we do
what's right for the team this is about empiricism it's about inspecting and adapting
if the team is more comfortable
with use cases maybe we'll use use cases we will use a combination of things
maybe we will use user stories but this
is all going to depend on how we define our process within
scrum again nowhere in scrum does it say you must use story points
is a practice that you may pull in to how you work to define that product
backlog items those are the items that of work or potential work they're
transparent so everybody can see them whether it's up on a actual whiteboard
if it stickies on a wall or using a tool like a JIRA for example or a version one
to manage that content that again is up to you with the transparent product
backlog and those items are transparent so everybody can see them discuss them
and decide how to work on them
I think they must contain clear acceptance criteria so that we
understand is this item actually done how do I test this item how do we
implement this item front from an acceptance perspective it may reference other
things like
models or specifications and security in other areas and they're going to be
sized so that they can be completed on an estimate within a single sprint
often we have to go through in break product backlog items down into smaller
pieces allow us to work on them more efficiently more effectively and deliver
on those item and then the sprint backlog that holds
the work for the current sprint just because something is in that sprint
backlog does not mean we commit to delivering it it's a forecast so what we
bring in there is what we forecast to be able to deliver
but things change things evolve and we may make decisions with our product owner
over that progress is again
transparent that Sprint backlog should be very clear and open to everybody to be
able to see it's owned by the
development team the product owner prioritizes that product backlog the
development team pulls those items in
during sprint planning to define this and it's adapted by that team throughout
as we go toward something we'll talk about shortly sprinkle
so what goes into that sprint backlog the selected product backlog items as PBIS
again it's a forecast not a
commitment for the development team and as they're working with the product
owner who has that ultimate
responsibility for what's being delivered I'm a plan often maybe includes tasks that
they're going to
deliver again against that sprint goal and at least one high priority process
improvement item and we'll talk about the retrospective in a few minutes but
this is a really important one this is added in the last version of the scrum guide why
is this important why do we
want to improve the team and why do we want to put it in our product or sprint
backlog well it as a product owner I get
focused very quickly and very easily on deliverables for my customers what
features are we going to add or what what new capabilities are we going to
add and those always end up taking the highest priority and team improvement often
gets pushed down so in the last
version of the scrum guide Ken and Jeff added this element which is at least one
high priority item for process improvement should be added to the sprint backlog for
every sprint to make
sure that we're constantly as a scrum team improving our process improving how
we work together and when this first came out there are a lot of questions we'll wait
why are we getting too
prescriptive why well the reason why is if we don't do this it gets ignored if
this gets ignored we just threw scrum out the door because we're not inspecting
we're not adapting we're not learning we're not being empirical this
is super super important for us and then the increment so what are we delivering
at the end the increment is the sum of all product backlog items for that
sprint it must be usable and it must work it
doesn't have to be released but it could have been made up of multiple releases
throughout that spring as well I worked on an on a scrum team where we were
delivering almost every day but we're
still running two-week sprints and we'd review that increment over those two of
the all of the work that was done and delivered over those two weeks again nowhere
in scrum does it say we can only
deliver once per sprint you can deliver as often is free going to use you need and it
must be done so one of the things
that's super important here in scrum is that definition of done defining what
what it means for that increment to be complete what
is it going to take for that increment to be complete and it must meet all of that
criteria I just wrote an article
that should be published shortly on security being a part of your definition of done
security should be in there if
our if what we're delivering is great a great set of features but we
haven't gone through our security checks we're not done we need to make sure
everything that it that that increment
needs to be deliverable to production is a part of that increment before it can
be called done that's why that definition had done is so important and we needed to
find that as a scrum team
with buy-in from stakeholders buy-in from our product owner
you I apologize there looks like
PowerPoint just crashed on me you're actually looking at live presentations
folks let me cause my sharing for a minute I reopen
PowerPoint
we have any questions so far while I'm while I'm reopening this
yeah we do have some questions we have a question here how can we use a project
vision and a release plan to do a forecast to convince old thinkers that are asking
when am I going to get the
final product and how much is that going to cost sure great question so we
absolutely do have a product vision we absolutely do have that vision as we're
as we're building out those features that the product owner is going to work
with as a matter of fact in Nexus which is a framework for scaling scrum we talk
about how we iterate on that vision
every three to three to five sprints and and the reason we do that is we you can
only forecast out so far you also don't know exactly what is required was
requested what is looking to be delivered until you start delivering some things so it
gives us the ability to start to forecast that out um but but I also recommend don't
forecast out too far
because you know it's going to change we've lived this day in and day out for years
there there's a lot of work that's
been done um one of my former colleagues Walker Rice did a lot of work on
forecasting and I believe the numbers were until you get within three months
of delivery you're you have a six-month window when you think you're going to
deliver it and
this was state backed up by lots and lots of data and lots of project
data that had been fed in is because we just don't know there's too much unknown
so we need that vision we need to be able to start to forecast out
we go out too far we start forecasting out too far chances are you going to be wrong
so
let's try to pull those things in I generally try to forecast out about three sprint which
generally gives us
enough information to get started and keep going so I think my screens back up
now sorry about that I'm not sure why PowerPoint just crashed on me you see my
screen yep sure do great
so the events and this starts to get to that forecasting so our sprint planning
sprint planning is where we look at the product backlog and start to forecast
what we can do within the sprint based on the sprinkle as defined by the scrum
team what is the goal and make sure everything is tying back to that goal we have
our daily scrum where we look at
progress and we'll talk through that by the way you notice here it doesn't say daily
standup it says daily scrum this
is a daily scrum number one you don't have to stand up maybe you decide in the
meeting you do you may have team members
who can't stand up you've just offended them by calling it a daily stand-up so daily
scrum we've
got our sprint review where we review that increment with our stakeholders we have
our retrospective where we come
together as a scrum team and talk about what happened what worked what didn't
what things we may improve and so on and
then this whole thing we've been talking about here is our sprint
so the Sprint it's a container for all activities and in the scrum event as I
said earlier that picture here this is one sprint we're delivering all of this
within that single sprint this it starts with sprint planning it ends with the
retrospective and all of those other
items are contained in between it's 30 days or less I've worked on teams that
do one-week sprints two-week sprints four week Sprint's but generally it's
within 30 it well it is 30 days or less not generally it is a sprint cannot last
more than 30 days and this is important it's kind of just evolved scrum and really
start working what they found was
and they've actually found a book on it called software in 30 days once you go
beyond those staff 30 day mark you start
getting feature creep you start losing focus the if you can't deliver some
value within 30 days you probably need to rethink what you're trying to deliver
doesn't mean the whole product but some
sort of value a one product trick that I worked on one product that I worked on we
were had a working homepage for we
were doing a whole new web deployment and building it with the goal was to build
out an entirely new web platform
and within that first sprint we had a working homepage to that website and we
were able to we didn't deploy it into production but it was it could have been and we
were able to start deploying that
though for stakeholders to give us feedback so we can learn and continue to evolve
that Kent oxen in the book and
has lots of case studies around how one for example there's a great video on our
website how he was working with fidelity and they were trying for six months to
deliver a new web-based platform for trading and he came in and sat with them
in within 30 days they had they had something that was working that people were
able to start to use what happened
was those six months before he joined there was lots of going back and forth we're
going to change this we're going
to do that we have to implement this whole big thing well as they started delivering
those big things they're trying to they ran into all kinds of problems and they were
delivering the wrong thing and this
feedback and that feedback instead of just deliver something small get feedback on
it and continually improve
and continually deliver it that's out of 30 days is so important sprint planning
product backlog is expected as defined by the product owner we define that
sprint goal why are we doing what we're going to do we look at and create the
Sprint backlog what is it that we're going to forecast for this sprint the scrum team
the development team work
together to deliver to think about the how and the entire scrum team is invited
to sprint planning the entire scrum team is there as part of that I just watched
the video by one of our professional scrum chain trainers Adama grill we talked
about how he when he runs his
sprint planning he has his development team members
start to pull in the items from the product backlog to the Sprint backlog the reason
he does that it starts the
conversations it starts us being able to look at what is it we're going to
deliver what do we want to deliver and how and ask the questions of the product
owner and making sure that we have that
done criteria for those items and so on so this is really an opportunity for the
scrum team to come together and based on the goal not pulling random things from
all over the place based on that sprinkle what are the items we want to try to work on
this sprint and forecast
that we can do the Sprint goal is an objective to be met during that spring
you've heard me talk already a lot about this sprinkle and I think this is so important
because it helps keep us focused one of the scrum values is focus
we need to stay focused throughout the implementation of those backlog items
we're going to look at the objectives as a tie back to the sprinkle
for flexibility because you know we're not gonna say we're going to deliver exactly
this set of features because
that's again a forecast but it's tied to the goal that we were going to deliver
capabilities for users to do axor we're going to deliver a working homepage those
sorts of things
and it's fixed throughout the sprint we're not changing our sprinkle every day we're
looking at how do we work to
achieve that sprinkle we change it every day it wasn't really a sprinkle it means
we're deviating from that sprinkle we're not really focused again losing that focus
you the daily scrum it's an opportunity for the team not to do a project status this
is not a status meeting it's an opportunity to continually inspect and adapt based on
our targeted sprinkle are
we moving toward that goal we need to replan what are the things
that we need to work on to achieve that do we need help now don't wait either one of
the biggest
mistakes I see are people waiting until the next daily scrum to bring up an issue bring
it up when it's when it's
urgent don't wait and if something happens an hour after this after the daily scrum
don't wait another 23 hours to bring up that issue as bring it up now but this is the
opportunity for the team to get
together the team to discuss it in constantly inspect and adapt its time boxed at 15
minutes if we can't have
this happen within 15 minutes and we're probably doing too much we're probably
trying to attack too much keep it
focused as well one of the things I do on my scrum team is we will do posts
crumbs so if we're going too deep into an item some they call it a rabbit hole or a rat
hole we'll say let's pull it
back the whole team doesn't necessarily even need to be involved but post scrum
on that and let's keep going through in really inspecting what we're working on
how our team is working and what are the things that we need to change so why do
we have a daily scrum we share those commitments as a team we identify any
impediments that might be getting in the way our scrum master may they help us
here it helps us create focus and
certainly increase and maintain awareness as a team and here's an
example of a daily scrum so the Sprint review the part that increment is
inspected with the stakeholders whether their customers marketing sales executives
whomever they should be
invited to that sprint review to give us feedback you don't see the word demo here
the Sprint review is not a demo you
do demonstrate how the product works and you demonstrate that product but but
it's not just a demo when I when I hear
the word demo and think demo I feel one-way communication here's all the stuff we
did this sprint thanks thanks
for watching and it becomes a sales process I'm going to sell you on and Hawaii
everything we just did was great
versus a review we're the development team is sitting with the stakeholders whether
virtually
or in person really reviewing the work that's happened helping to get feedback
so that as we go into sprint planning for the next sprint we're able to take
that feedback and adapt how we work adapt product backlog items and so on
getting that information is so critical because if we're not delivering value if
we're just delivering I'll say inside out if we're delivering what we want but
the customer the user doesn't want it are we really delivering value versus
outside in getting that feedback and almost instant feedback right 30 days or less
now I know that I'm delivering what
is expected I'm getting feedback on that delivering helping to deliver the right thing
so some mechanics for the Sprint review
on the product owner shares what was done what wasn't done where we are with
the backlog again transparency here its ultimate transparency development teams
share is the actual increment that that work what happened during the sprint how
they dealt with issues when everybody
provides feedback not excuse for self congratulation it's about inspection and
adaption providing that feedback now granted congratulations good job is good we
want
that feedback too we want happy teams but it's not about selling and I think that's
what that means there is we're
not there to sell all of our stakeholders and why they why they want this it's about
communication and in an
absolutely positively a two-way communication the Sprint retrospective
at this point it's just the scrum team members we don't have anybody from outside
the scrum team here because we
need to feel protected we need to feel that this is a safe place for us in the scrum
team to talk about what worked
what didn't work what do we need to improve what got in the way of us
working together as a team and this is a really important meeting or event and I
find it to be one of the most valuable ones because it really is about inspecting how
we work as a team and
adapting as we move forward working together to do that
and this is where the scrum values start to really come in update they come in
throughout but the scrum values are so
important we need to respect everybody in this meeting we need to have the
openness in this meeting we need to be
able to have those conversations those hard conversations as critical crucial
conversations as a team to keep working and keep working in the right ways
so just to give you some ideas and and this is out right out of the scrum guys each
event and if we're doing say a
30-day sprint a three-week sprint a two-week sprint one week sprint about how long
those how long those meetings
should last and this is a time box it's interesting in the last version of the scrum
guide Ken and Jeff had to add
something defining the time box saying no more than me that's the definition of
a time box but it came up being questions all of the time so it doesn't mean you have
to fill eight hours just
because it says sprint planning for 30 days takes 8 hours if you can do it in 4 do it in
4 don't find excuses to make an
8 just try to time or do time boxes no more than 8 hours if you think of it
that way now same thing with the daily scrum now this daily scrum this time box no
matter how long the Sprint is at 15
minutes but if today we can finish it in 10 don't find excuses to talk just to
talk by this meeting that's when people start to actually lose the value that they're
getting out of the meeting but by keeping focused
we actually get a lot more value as a team and we stopped going through the
motions and actually start interacting
together so a few other items I wanted to cover product backlog refinement um what
does
refinement mean now some of you who are on I know there was I think 30% or so
views that you you already do scrum you may have heard the word grooming
grooming was changed to refinement due to its meeting in certain languages so a
product documents backlog refinement it's an optional practice but we talk about it a
lot in scrum in actually in
the scaling framework Nexus it becomes a primary event because it becomes more
and more important as we scale scrum from one team the multiple teams working
together and product backlog refinement
is our opportunity to discuss the items in the current product backlog
understand what those are work with the product owner as they're prioritizing
those items but also breaking down items something may be a very very large item
can we refine that down into a set of items that allow us to work on it
more usually when we get to sprint planning allow us to break that up so we can
deliver a piece of that functionality for example maybe I have this enormous
user story which really come in terms could be an epic broken into lots and
lots of user stories let's do that so we can focus in on delivering the right
things and that's the product backlog we find it lastly the definition of done
talk a bit about this earlier it's that common denominator of quality for the product
with that definition of done
helps us all agree what it means to have a done item what
it means it needs to be to be considered done releasable
product increment definition of done is transparent across the team so we're not
having different
definitions have done across the team every every item needs the same definition of
done so we can share that
responsibility as we're getting to release so in summary scrum implements
empiricism and we've had focused a lot today in software development or software
delivery and the empiricism is
so critical here it's about constantly changing evolving our process pulling in the
right
practices we announced a few weeks ago scrum with Kanban for example where
scrum teams where it makes sense can both pull in certain practices from combine
to build out and define their
overall process based on that scrum framework not changing scrum but adding
practices just like we've done by adding
XP practices by adding test-driven development practices by adding user story
practices as an example those are
all practices that pile on top of scrum to help me define my process it's about
that empiricism it's about constantly evolving to make sure we're delivering the right
thing every scrum roll there are three of them has clear accountability there's three
scrum artifacts those artifacts are and need to be transparent and all of those events
help
me inspect adapt and evolve via transparency if I don't
have these things I am not doing scrum I may say I'm doing scrum but if I'm if I
don't have these things if we're not constantly inspecting and adapting we're not
really doing scrum unless you've got
it perfect if you've got it perfect you know let me know because I'd love to come work
for you so with that I'll open up to questions
okay great we have a lot of questions here maybe more than we can get to but
we'll try to go through them have one question so the scrum rules that you
mentioned do
not include the manager role which can cause some confusion and scrum adoption
and many companies so what's your take
on that and how would you address that sure so manager still exists in our
organizations and they do but the manager is not a role within scrum I
don't need a manager to be able to deliver
product that manager generally will be a stakeholder to the scrum team and work
with the scrum team as a stakeholder but they're not a part of the scrum team unless
they are also on that development
team and there may be people who have the title of manager but we need to also
be able to flatten that out a little bit but there so in Indian scrum teams that
I've worked on there are always been managers above that scrum team that through
the HR functions that help
manage team members from day to day and
so on but at the scrum team level we need to be able to self-organize how we work
what we do and when we do it the
minute you start getting command and control of a manager tells everybody what to
do we've just lost empiricism
we've just lost the ability to inspect and adapt on a daily basis to continue to work it
doesn't mean Pro them out
doesn't mean throw out all of your managers managers are important for many
many reasons within an organization as a
matter of fact we've got a course you can see there on the lower right Palli
professional agile leadership
essentials that's a great course where managers learn their role in helping the
the scrum teams be successful managers play a great role in helping those teams
be successful but doesn't mean they have to be on the scrum team itself
okay how much should the scrum master help the product owner an example given
was ticket refinement so that that's really going to depend team by team
there's not a clear answer it depends on the team and the team is going to learn
and that may evolve and change over time the product owner is still going to be
ultimately responsible for it what you
need to be very careful of is making the scrum master into the meeting planner and
scribe
they may do that but that's not their job their job is not to be the person
who just schedules all of them the events and takes notes at the events
our scrum team member and they may work with that product owner too to help
where needed but there's no hard and fast Oh 10% 20% it's going to depend on
how that scrum teams working on how their forms they may find that the scrum
master is doing too much work with the
product owner and in really doing the product owners role now we have a different
issue that needs come up
during the daily scrum or need to come up during during the retrospective where
we need to figure out how do we address that if we if we have an absentee product
owner now we've got a different
issue and maybe we need a new product owner
great is the scrum master part of the development team or is their role solely
as the scrum master so their role the scrum masters role is as the scrum
master their part of the scrum team not a part of the development team and in
there's important reasons for this that
the product owner is not part of the development team the scrum master is not part
of the development team and there's
a good video that evylyn ruse just recorded on why this some makes sense
and it's posted up on our website the minute the scrum master and a
product owner are also responsible for delivery on the development team there's a
conflict of interest so I'll pick on
the product owner first if the product owner is also on the development team
guess what's going to get worked on and guess what's going to take priority the
things that they want to do which make
sense to a point but don't always because it needs to be
a team effort and in a team thing same thing with the scrum master well I'm
going to make sure everybody takes care of my impediments first or maybe there's a
something that I think is highest
priority but the team doesn't agree guess what I'm going to work on that you start to
get that conflict of interest
the minute the person who's supposed to be supporting the team and helping to
mentor the team and can coach the team
and deal with impediments and so on is also just a part of the team that's delivering
so keeping those roles
separate are really important everyone's got a couple of great examples in our video
you can check them out or shoot me
an email and I can play it to them
besides the latest scrum handbook what would you suggest for people new to
scrum what kind of resources would you suggest for getting the best handle on
scrum sure so to get started I go to the
scrum dog website if you under resources you'll you'll see right under what is scrum
under resources and there's a
whole number of resources around including videos ebooks blog posts and
so on including around each role each event in each artifact that helped you
learn so the scrum dog website is a vast knowledge of scrum when I talked about
who we are what we do yes we do training yes we do certification but a large
number of the people who come to our website are coming to learn and learn to left
directly off of that we also have a
forum where you can you could ask questions and we've got scrum experts
who are answering those questions from all around the globe with their experiences
there's a lot of resources
videos webcasts like this one white papers and so on all there as well as a
list of recommended books software in 30 days is a great book by Ken and Jeff
Ken's first scrum book enterprise scrum another great one that real
we will help people understand how you apply scrum within a real organization
great what are the biggest challenges you've seen on teams implementing scrum
and what are some ways to overcome those that's a it's a pretty broad question so
a couple of things that I've seen that kind of stand out one is where the scrum
team isn't truly left independent their scrum team by name yet there's managers
in there every day telling them what to do how to do it and when to do it that's where
you need a really strong scrum
master who has power and the ability to push back and really protect and what a
scrum masters roles is protecting the scrum team and protecting its independence
the minute we start to get
into command and control we lose that that's probably one of the biggest
failures that I've seen another is going through the motions either you're doing
scrum me or not just take those roles seriously take the offense
seriously take the artifact seriously we're either doing scrum we're either following
the scrum guide and we're not
and I don't mean that from a religious perspective of do scrum or don't do
scrum I only those other other practices
pulling the things that you need to be successful but don't deviate from the scrum
guide either don't don't say oh
well you know we're instead of doing a daily scrum we're going to do it weekly well
and I've seen this and I've had
conversations with folks who try that and guess what it really becomes a status
meeting and they're not
constantly inspecting into that thing they're not learning they're off doing their own
thing and then they come back
together and give status on their own thing they're not doing scrum as it's meant to
be done next question you know
we have someone here says they feel that people keep mixing up scrum and agile
and wonders if you can define the
difference between the two so agile the mindset there are lots of ways to be
agile agile is absolutely a mountain inspection and adaption but
scrum is a way to be agile it's the most
popular agile framework based on survey data and I've seen from lots of different
resources but scrum is just
one of the many ways I can be agile agility itself is about look constantly
learning inspecting constantly changing how we
work adapting and and what scrum does is give us a way to do that so if that
helps if if a team execute SAS print up three
weeks for example could they next sprint change the time length say to four weeks
they absolutely can there's nothing in the scrum guide that says you must
always do the same sprint length but what I recommend is
don't jump all over the place don't do two weeks 4 weeks 2 weeks 3 weeks right try
to keep it as a steady pace that
said I've worked on scrum teams where for example our normal cadence was
always 2 weeks but there were a couple of things we really wanted to focus on and
deliver very quickly and so we set a
sprinkle we shortened our sprint to 1 week although we only did that for for
one sprint or might have been for two sprints and we set a very specific
sprinkle for that sprint and what that allowed us to do is get really really
intense focus on on that sprinkle for that sprint it helped us do some
different things but what I would I don't recommend so I recommend is that you try
to stick
to a consistent sprint length if you do need to change don't change all the time
people in general people are creatures of habit and if we start jumping all
over the place we're going to lose focus we're going to be disruptive and we'll find
ourselves less effective instead of
more okay
yeah when managing multiple projects would you consider having a single scrum
for the projects or keep them separate per project so it's a hard one because
everybody defines project is something different I don't know what what this person
means by project what I would
look at it is you want a scrum team or you want you want a set of scrum teams
per product in a single product owner for that product and you may scale that
to multiple scrum teams so again if you check out our website and under resources
you see scaling scrum with
Nexus and the Nexus firm work framework that Ken created helps define that better
in that framework what we focus
on here is how multiple teams can work together to deliver
an integrated increment within a sprint so rather than having one scrum team off
doing their thing in another off doing their thing the scrum teams are working
together delivering that integrated increment
they may have one scrum si may have multiple scrum masters but they only have
one product owner because it's
because they're delivering on a single product on so I generally try to break it down
by product and that's how scrum
breaks it down and so project I'm not
sure because I'm not sure of the full context but I hope that helps
okay we're close to the top of the hour here we still have time here for a
couple more questions if that works for you Eric yep absolutely okay what advice
would
you give about working with scrum and remote team participants sure I've got a
great example that my last scrum team that I was working on actually my
current scrum team as well we have remote participants a couple of things make
sure your product backlog and your
sprint backlog are transparent use a tool don't throw it all up on a whiteboard that
nobody can see use video
for your for your events so that you're all able to see each other because in
expressions are just as important as the word sometimes more so make sure you're
using video whether it's something like hangouts or Skype or GoToWebinar like
we're using today so you're all working together um make sure you're always and
this is actually in the scrum guide as well and we talked a little bit about it your daily
scrum should always happen the same time every day
to make sure that we're all on that same timezone if you can stay within the
small number of timezone that's more helpful but not always possible but but
that's certainly helpful but really communication using some sort of instant
messaging as well as using the video is key as an artifact on um a current scrum
team we we have a video up all the time where we can always walk in and chat
people are always on ik communicating so we're even though we're virtual we're
working as as a team and really acting as a team
I think we probably have time for maybe one more okay does it make sense to have
the Sprint review with only the dev team and product owner participating so get
your stakeholders there if you're not reviewing your stakeholders there's a
term I've used but I'm not going to you're preaching to yourselves you're not getting
the feedback get
stakeholders involved as best you can now your stakeholder may only be your
product owner if that's the case that's okay if you can start to get some of the other
stakeholders involved so one of my
scrum teams for example I was the product owner I always invited my CEO to
our two more small small organization but I was invited by CEO because because
he was a key stakeholder to every Sprint review I always invited our marketing team
to
every sprint review and so on they were stakeholder than what we were delivering so
try to get some of that feedback well
you want to be careful of in that instance do you have to have the stakeholders there
no as long as your
product owners are representing the stakeholders but if that's the case you
have to be very careful that you're not that you're not feeding back feedback
that's just inside the team make sure you're thinking outside and broader from the
team
so I think we're at times I again I apologize for that little blip in
PowerPoint not sure what happened there or why powerpoints decide to crash but it
did so I want to thank you and feel
free to reach out to me directly my email address is Eric neighbor nai bu RG
@ scrum org or you can find me on twitter at Hattie neighbor again thank
you and have a good rest of your day great thanks very much Eric for a great
presentation today I'd also like to thank today's sponsor scrum org for providing the
d-zone audience with a
wonderful webinar presentation and lastly thank you to everyone who joined us
today we hope you learned something
new that will help you in your developer career have a great day and we'll see you
next time

https://www.youtube.com/watch?v=-xudUyGsNfc