Scrum, as I’m sure you’re aware, is one of a number of Agile Methodologies.
Oops. One line in and I’m made a mistake: Scrum is not a Methodology.
Scrum doesn’t prescribe a specific method: it’s more correctly described as a Framework.
So, yes: Scrum is one of a number of Agile Frameworks.
And like all Agile approaches, it is an iterative process.
Is that right? Is it iterative? Or is it incremental?
In fact it’s both iterative AND incremental… as we’ll see in due course.
For now I’m going to back up a little.
For most of us in business, our job is to build or develop something - be it a product or service - and deliver it to a customer or customers.
But build what?
Well, something that the customer wants. Something that the customer values
Trouble is, it’s devilishly difficult to figure out what a customer wants.
Yes we could commission research. And spend months designing, building.. Testing…
But we’re likely to find that we’ve missed the mark:
We’re created something that the customer doesn't want.
Or something that customer did want. You know, in the past. But not now.
All that time - MONTHS! - all that money - wasted
What you see here is usually described as Waterfall process. So named because work cascades from one process to the next.
It’s a death-or-glory, winner-takes-all approach. You got one shot to get it right.
Me, I’m not a gambling man. I prefer to have more bites at the cherry. More chances to get things right.
And that’s where Agile comes in
Instead of delivering the entire thing, we break things down and deliver a piece at a time. We deliver in small increments.
That’s the “incremental” that I mentioned earlier.
Why would we want to deliver in a piecemeal fashion?
Well, the sooner we get something into the hands of the customer, the sooner we get paid.
(And that’s always a good thing.)
But more importantly, every time we deliver something to the customer, we get the opportunity to learn:
Notice how this gives us the luxury of being wrong! Incremental delivery means that we have plenty more opportunities to get it right.
Notice also that we no longer have to rely on what the customer says she wants.
If you want a simple analogy:
In waterfall, the assumption is that we’re on the right track. Much Like throwing a rock at a target
In Agile, the assumption is the exact opposite. that we’ll get it wrong…. But that we’ll also get the opportunity to learn… and to correct our course.
Time to flesh this out a bit:
These are the increments.
And this feedback loop - and the fact that we go round and round - these are the iterations .
We’ve talked about waterfall. We‘ve talked about Agile. I think it’s time we got into the details of Scrum.
Allow me to introduce the team:
The development team is responsible for delivery.
The Product Owner is responsible for the “evolution” of the product.
And then there’s the Scrum Master.
The title is slightly unfortunate: there’s no command and control role here. The role is very much one of servant leader: helping the other to develop and maintain good habits.
Let’s give these people some tools to work with.
This is the Product Backlog
What’s the product Product Backlog I hear you ask?
Feedback from the customer, together with input from other stakeholders, goes in to the Product Backlog.
The Product Backlog is a prioritised list of (mostly) User Stories.
It is maintained and managed by the Product Owner.
It is a dynamic list. It can - it must - change all the time.
Okay, we have our Product Backlog and we have our Scrum Team..
We’re ready to set to work.
The defining property of Scrum is, of course, the Daily Scrum.
Err, no. That’s not correct. It’s actually the Sprint.
A Sprint is a fixed period of time, usually 2 weeks.
(Other time periods are available. A month tops.)
The Sprint is the vessel - the box, the container - for a number of Scrum events. Starting - right at the beginning of the Sprint with Sprint Planning.
This is where the Development Team the Product Owner and the Scrum Master get together to decide what the Development Team will tackle in the current Sprint.
Notice that it’s not the Product Owner that decides, although she provides strong, indirect influence by way of the (prioritisation of the) Product Backlog.
The items selected for the Sprint are known as the Sprint Backlog.
The team will work on these - to the exclusion of all else - for the duration of the Sprint.
So the team set to work, starting each day with at standup meeting: the Daily Scrum.
Remember … Waterfall?
It’s pretty easy to organise a Waterfall project: put all the designers in one room, all the developers in another, all the testers in another, etc.
But in Agile generally - and in Scrim specifically - we don’t have the luxury of working in such a sequential way.
Instead of doing everything once (as happens in Waterfall). we go through the whole cycle - from design to development to testing - in just two weeks.
And usually more than once!.
With just 10 working days to play with, there’s no time for sequential work.
The team has to - MUST! - work together. So coordination is paramount. And that’s the reason for a daily meeting.
And that’s how it goes, day after day, with the team racing towards the Sprint Goal.
As the Sprint Guide puts it:
“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.”
Now this is something that gets confused. Notice that the Scrum Guide says “potentially releasable”.
The “potentially” part is important:
The team doesn’t have to release it.
Nor does the team have to wait until the end of the Sprint to release it. In these days of continuous delivery, there may be multiple releases during a Sprint. And that’s all good.
And that’s the end of the Sprint. Isn’t it?
No, it’s not the end of the Sprint.
Although release don’t wait for the end, there are a couple of Events (ceremonies) that do:
The Scrum Guide again:
” A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.”
To understand the importance of the Retrospective, we need to step back and look at the winder view.
Waterfall is a game that’s played exactly once.
In iterative development - such as Scrum - , we play a new game every two weeks.
So we have the opportunity to get better at playing the game.
So the Sprint Retrospective - “retro” for short - is an opportunity to the team to look at: what worked, what didn’t, and what can be improved.
A discussion of Scrum would not be complete without mention of the Scrum Guide.
Yes. Scrum is codified. It’s written down.
I encourage you to check out out.
You'll find many of the things we looked at today.
We have the Scrum team
And the Scrum artifacts:
And the Scrum Events:
I set out to produce the definitive Scrum video, and I haven’t even managed to cover the main points of the Scrum Guide.
The eagle eyed amongst you will have spotted the omission of the Scrum Pillars:
And the omission of the Scrum Values:
But I’m okay with that. You see, that is not just an episode about Scrum
It’s the first of a series of episodes about Scrum…
… that will be produced - believe it or not - using a Scrum process.
What you’ve just watched is the first increment.
The next increment? Well, that, to a large extent, is up to you.
Should I dive into the things I missed?
Or should I expand on something that I did cover?
Let me know in the comments below.
Watch "Scrum Overview - [Scrum Basics 2019] + FREE Cheat Sheet" on YouTube.