- If you've found this video,
the chances are you were just searching for Scrum.
And if so, I have a fantastic video for you.
Sadly, there won't be any of this.
(announcer talking in the background)
But there will be some of this.
And just a sprinkling of this.
And if you hang around to the end,
I'll tell you how to get your hands
on this rather lovely cheat sheet.
Hi, my name is Gary Strong,
welcome to Development That Pays.
We do a video like this every Wednesday.
Sometimes every other Wednesday.
And it would be great to have you along.
Click that red button to subscribe
and remember to hit the bell so you don't miss a thing.
Scrum, as I'm sure you're well aware,
is one of a number of Agile methodologies.
(alarm ringing)
Hmmm, seems there's a lie detector in operation.
It's true though, Scrum is not prescriptive,
it doesn't prescribe a specific method,
so it's more correctly referred to as a framework.
So yes, Scrum is one of a number of Agile frameworks.
And like all Agile approaches, it is an incremental process.
Is that right, is it incremental?
Or should that be iterative?
In fact, it's both: incremental and iterative.
As we shall soon see.
For now, I'm going to back up just a little bit.
For most of us in business our job is to build something,
be it a product or service, and deliver it to a customer.
But build and deliver what?
Well, something that the customer wants.
Something that the customer values.
Trouble is, it's devilishly difficult
to work out what a customer wants.
Sure we could commission some research,
and spend months designing, even more months building,
and a few weeks testing, but we're highly likely to find out
that we missed the mark, that we spent months,
possibly years of our lives, producing something
that the customer just doesn't want.
Or perhaps something that the customer did want,
but doesn't want anymore.
All that time, all that money, wasted, down the drain.
What you see here is usually
described as a Waterfall process.
So named because work cascades from one process to the next.
It's a death-or-glory, winner-takes-all kind of approach.
You get just one shot to get it right.
Now me, I'm not much of a gambling man,
I'd much prefer to have more than one bite at the cherry,
more than one chance to get it right.
And that's where Agile comes in.
Instead of attempting to deliver the entire thing,
we instead deliver in small increments.
That's the incremental that I mentioned earlier.
Now why would we want to deliver in a piecemeal fashion?
Well, for one thing, the sooner we deliver
something of value to the customer,
the sooner we start to get paid,
which is always a good thing.
But more importantly, every time we deliver
something to the customer, we get the opportunity to learn.
Did it go down well, or did it go down like a lead balloon?
Does the customer want more of the same?
Or do we need to change tack?
Notice how this gives us the luxury of being wrong.
Incremental delivery means we have
plenty more chances to get it right.
To give you a couple of simple analogies.
In Waterfall, the assumption is
that we're always on the right track.
So a bit like throwing a rock
and expecting to always hit the target.
In Agile, the assumption is the exact opposite.
That we will probably get things wrong.
But that we will be able to learn and adjust our course.
Much like an airplane in flight.
Time to flesh this out a bit.
We decide what to build, remember, something small.
We build it, deliver it, and learn.
Feeding that learning back into the system,
before deciding what to build next.
Building it, delivering it, and so on.
These are the increments,
the things that get delivered to the customer.
These are the iterations, like I said before,
Agile is both an incremental and an iterative process.
Okay, we've talked about Waterfall, we've talked about Agile
it's now time to get into the detail of Scrum.
Ladies and gentlemen, allow me
to introduce you to your Scrum team.
We have the Development Team,
the Product Owner, and the Scrum Master.
The Development Team as I'm sure you'd expect
is responsible for delivery.
The product owner is responsible
for the evolution of the product.
And then there's the Scrum Master.
Now that term, Master, is slightly unfortunate,
because there's no command and control here.
The role is very much one of servant-leader,
helping the others to adopt and to maintain good habits.
Let's give these people some tools to work with.
This is the Product Backlog.
What's the product backlog I hear you ask?
(alarm ringing)
Oh, you weren't asking?
Well, I'm going to tell you anyway.
This feedback together with input from other stakeholders
goes into something that we call the Product Backlog.
It's a prioritized list of mostly user stories.
It's maintained and managed by the Product Owner.
Okay, we have our Product Backlog nicely organized
and we have our people, time to set to work.
The defining property of Scrum
is of course the Daily Scrum.
(alarm ringing)
No, it's not the Daily Scrum, we'll come to that in a second
the defining feature of Scrum is actually the Sprint.
The Sprint is a fixed period of time
most commonly two weeks,
but other time periods are available,
up to and including one month.
The Sprint is, I guess you could call it,
a container or a vessel for the other Scrum events.
And the Sprint starts with the first
of those events, Sprint Planning.
This is where the team gets together
to decide what to build in the current Sprint.
Note that it's the Development Team,
rather than the Product Owner,
that has the final say on what will get built.
Although the Product Owner does have a strong influence
on that, by virtue of the Product Backlog.
As we said before, the Product Backlog
has the most important items pushed towards the top.
The items selected are known as the Sprint Backlog.
And the team will work on these items,
ideally to the exclusion of all else,
for the duration of the Sprint.
Sprint Planning over, the team sets to work.
Beginning each day during the Sprint with a Daily Scrum,
otherwise known as a Daily Standup Meeting.
Remember we talked about Waterfall?
Well it's actually pretty easy
to organize a Waterfall project.
You put your Designers in one room,
your Developers in another room,
your Testers in another room.
There's not that much need for coordination.
But you can get away with that
if you have a project that runs over a series of months.
If your project effectively runs for just a couple of weeks
that's the situation we have in a Sprint
then you don't have the luxury
of finishing one item before starting another.
A scrum team has got to go through the full gamut,
from Design, to Development to Testing and beyond
in the space of just two weeks.
With just ten working days to play with,
the team has no choice but to work together.
So coordination between the team members becomes paramount.
And that's the reason for a daily meeting.
To allow those ducks to become,
and to stay, in alignment.
And that's how it goes on, day after day,
with the team racing towards its sprint goal,
a potentially releasable increment.
Now this is something that gets confused.
But notice that I said potentially releasable.
So there's no compulsion to release
what's being built during the Sprint.
Nor is there a need to wait to the end
of the Sprint before releasing.
In these days of continuous delivery,
there may have been multiple releases during the Sprint,
and that's all to the good.
And that brings us right to the end of the Sprint.
(alarm ringing)
Oh, actually no, that's not the end of the Sprint,
we still have two things that we need to do.
The first thing, the first event,
is the Sprint Review.
It's an opportunity for the Scrum team
to showcase what they've been working on
during the course of the Sprint, to showcase the increment,
and in that sense it's a meeting
that is focused on the product.
Contrast that with the next event,
which is the Retrospective meeting
that is focused on the process.
To understand its importance, consider that Waterfall
is a very long game that we play just once.
In iterative development, like in Scrum,
we play the same game again and again.
So we have the opportunity to learn
how to play the game better.
And that, that's the purpose of the Retrospective.
Any discussion of Scrum would be incomplete
without reference to this, the venerable Scrum Guide.
Yes, Scrum is codified, it's written down.
It's one of the key reasons, I think,
that Scrum has enjoyed such popularity.
I encourage you to check it out,
I've put a link in the description below.
In the guide you'll find many of the things
that we've looked at today, the Scrum Team,
the Scrum Artifacts, and the Scrum Events.
What you won't find in the Scrum Guide
are any pretty pictures, but you will find
some pretty pictures on this rather lovely cheat sheet.
The imaginatively named Scrum Cheat Sheet.
Getting your hands on a copy is simplicity itself,
you'll find a link in the description below.
Click the link, follow the instructions,
and it's all yours, together with any
and all updates that I make over time.
The Scrum aficionados among you will have noticed
a couple of glaring omissions from this episode.
We haven't yet talked about the 3 Pillars of Scrum:
Transparency, Inspection, and Adaptation.
Nor have we talked about the 5 Values of Scrum:
Commitment, Courage, Focus, Openness, and Respect.
So this falls short of being
the definitive video on Scrum.
But I'm okay with that, you see,
this isn't just a video about Scrum,
this is the first of a series of videos
about Scrum that will be produced using a Scrum process.
What you've just watched is the first increment.
The next increment, well, that's up to you.
Should I dive into some of the things that I missed?
Or should I expand on some of the things that I did cover?
Let me know down there in the comments below.
Thank you very much for watching.
If you enjoyed this episode please give it a thumbs up.
Share it with your network.
And remember to subscribe for
a brand new episode almost every Wednesday.
I look forward to talking to you again soon.
Cheers for now.