So we're going to talk about how to get agile with Scrum, how do you bring more agility into your organization.
I grabbed this quote out of this article, because I like this quoted, I think it gives us a good feel for what Scum is about.
Nobody is doing Sc rum in 86. What happened is a couple of Japanese researchers wanted to find out what was working well in product development,
not software development.
They went around and they studied successful companies.
They labeled what they saw, Scrum.
So that's where the name Scum came into things.
These authors wrote that the relay race approach to product development.
Now most of us are software people.
What's another word we use for relay-race approach?
What do you think they're talking about there?
We're software people, right?
What's the big nasty process?
Waterfall, all right.
Talk about waterfall.
So the waterfall approach may conflict with the goals of maximum speed and flexibility.
They say instead what we want is a holistic or rugby approach.
There's where this word scrum's going to come in.
It's part of the game rugby.
And they say we have this rugby approached where a team tries to go the distance as a unit, passing the ball back and forth,
and that may better serve today's competitive requirements.
Focus on that last phrase for a second.
Today's competitive requirements.
Remember when I told you this was written?
1986. They were saying waterfall doesn't work.
It's 1986 and waterfalls too slow for us.
We need something better.
What are we doing thinking 26 years later that waterfall might even possibly work?
Today's competitive requirements, 2012, 2013's, competitive requirement, we absolutely need something that is going to lead to faster and more flexible products.
This is where Scrum is gonna come in.
So Scum gets its name from rugby in the middle there.
And fortunately, I played rugby one drunken day during university.
So I can explain what a scrum is all about from that one drunken day.
We used to play American football every Saturday when I was in university.
The guys in my dorm, we'd get together, play America football, every saturday.
One Saturday we had a guy from London who said, no, now we're playing rugby next week.
And we said okay, you have to teach us how.
He did, he taught us to how to it.
I'm not sure all of his rules were the official rules.
which explains why it was a drunken Saturday.
One of his rules was the mandatory beer break every five minutes.
So every 5 minutes, we'd run over the sideline, have a beer, and come back and start up again.
And the thing I remember from him teaching us how to play, my job, I lined up over here on the right side.
I was in the front of the line of three people.
Had my left arm out.
Steve, our guy from London, was over on here the left side with his right arm.
In between us was third guy.
We were actually holding him up.
He didn't have his feet on ground.
And our job was to push forward, the guy without his feet on the ground, his job is to kick the ball.
The ball was rolled in between us like a puck would be dropped in a hockey game.
And so this was this metaphor for what software development was all about.
It was just this idea of kind of a chaotic environment, everybody with their own special responsibilities though, but a very common purpose.
We were locked together, we had our arms around each other.
The guy in the middle, for example, if he took his arms away, he'd fall down on the ground.
So we had our arms together pushing for a common purpose.
This is where this metaphor came from.
I work with a lot of different companies in the US and Europe.
And one of the companies I've worked with off and on for the last 24 years has been Apple.
I want to just share a little quote from Apple here, actually from an article about Apple, this is from article in Time Magazine,
a news magazine in US.
The author in here wrote that Apple employees talk incessantly about what they call deep collaboration.
cross-pollination or concurrent engineering.
Essentially means that products don't pass from team to team.
There aren't discrete sequential development stages.
They said instead it's simultaneous and organic.
Products get worked on in parallel by all departments at once.
Design, hardware, software, and endless rounds of interdisciplinary design review.
If you ask Apple what they're doing, they call it their own thing, the Apple process.
But this is very much Scrum.
This is what Scum is doing here.
So, Sc rum is about these lack of handoffs, it's about working together, interdisciplinary design, all working deep collaboration.
I just want to list a couple of the companies that Scrum has been used in.
I'm not going to read all those.
You can take a look at these.
By the way, this presentation is on my website.
This presentation in fully available in PowerPoint and Keynote format for you to grab and make your own.
So you've got to go back and introduce Agile or Scum to your organization.
And you can use this representation.
The slide was really useful 10 years ago when I first started putting a lot of this together, because people then were wondering,
well, who's using Sc rum?
It's kind of a dumb slide now, just about everybody's using Scrum, right?
We can make thousands of companies on a list like this for people who are using scrum, so it's not that unique anymore.
Scum's also been used in just every type of application, video games, Department of Defense in the U.S., government applications,
commercial applications websites.
federally regulated banks.
In fact, used by the main bank in the US, our Federal Reserve.
It's used in medical devices, so Scrum is used on just about anything.
A couple of the characteristics of Scum.
Scums focused on having what are called self-organizing teams.
Self-organizing team means that we do not have one person, typically called a tech leader, something like that, who gets to assign out all the tasks.
Why don't you do this?
You do that.
You did the other.
Oh, and I'll do the fun thing.
We don' have that person on a Scrum project.
On a scrum project, the team self- organizes.
They're given a challenge.
Build this.
we need it by the end of the year.
And the team figures out how to do that collaboratively.
They work together.
Hey, I was thinking of doing this.
Well, so was I.
Why don't we work on it together?
So the teams together figures who's the appropriate person to work something.
There's not one person who gets to delegate that task assignment out.
Another characteristic of Scrum is that the product or project is built in a series of what are called sprints.
Each sprint is anywhere from one to four weeks, no longer in a month.
Some teams do calendar month sprints.
Those are very rare.
Most common, two weeks.
So teams will work in these little two-week increments, and they'll build some part of the product each two week.
Every two we get to see what the team has worked on, give feedback on it or get feedback, show it to customers.
And we use that information to inform what to do next.
Do customers like what we build?
Scrum uses something called a product backlog.
So this is a term we'll hear during a session on the product back log, the end of the day today.
The last session will be on product the backlog, and something call user stories.
You've heard much about agile, you might have come across this term, user story.
There's just a way of capturing requirements.
I was saying that the Product Backlog is it prioritized, features list.
It's a list of things we want, prioritised by somebody we call product owner.
One of nice things, I think, but also a dangerous thing about Scum, is it doesn't prescribe any engineering practices.
Scrum doesn' t say you have to do test-driven development.
Doesn't say that you need to pair a program.
It doesn t have automated testing.
In fact, it does not say it has to test at all.
All right, Scum doesn''t say anything about the engineering practice.
The engineering practises are left where they should be for the team to figure out.
Now, all those things I just listed, I think, are all good things.
Scrum doesn't say you have to have version control.
I've never met a good Scum team that didn't.
But that's up to the Team to Figure Out.
What's nice about this, what this means, is that Sc rum is a general purpose project management framework.
Scrum can be used for all sorts of things, not just software.
In fact, if you think back a few minutes where I said it originated, it originated in product development, Not even software development.
Scum started to take off when it hit the software world, because software has such a need for speed and flexibility.
But, scrum can used anywhere.
One of my favorite examples is every year there are examples of people who plan their weddings with scrums.
Think about that.
Normally, things like pick spouse are already done.
But the rest of the product backlog has things, like picked the venue, picked a caterer, create the guest list, pick the music,
all that type of stuff.
So people will use Scrum to manage all sorts of projects.
That wouldn't make any sense to plan a wedding if you had test-driven development.
How do you do that?
One of the things that is nice about Scrum 2 is it's fairly straightforward.
It's very simple.
There's no 200-page rule book on Scum.
And there's not this massive list of rules.
You've got to do this, you've gotta do that, and you gotta this.
The few rules that we do have in Sc rum are what are called generative rules, Generative rules.
They're there not so much because we care about the actual following of the rule, as we about care the behavior that following that rule generates.
So one of things you might have heard about Scrum is we have a daily stand up or daily Scum meeting.
Teams come together and talk once a day for 10 to 15 minutes.
I don't really care that we get together.
I really don' care we have those 15 minutes of discussion.
What I care about is the discussion it creates.
So we've learned that having teams talk frequently is a great thing.
One of the easy ways to generate that behavior, that's what we want, is to put in place this rule.
Get together once a day and talk.
It's not the rule that you care as much as the behavior that it create.
And I mentioned that Scrum is one of the Agile processes, lots of different other Agil processes.
Feature-driven development, adaptive, Kanban, extreme programming, Lean, DSDM, Crystal.
I don't know if I've already mentioned one.
Lots of other agile processes Scum is the most popular.
Recent surveys showed about 70% of people doing Agiles were doing Sc rum.
So Sc Rum by far the more popular Now here's where Scrum is the most successful.
This is a graph showing the mapping of on the horizontal axis how uncertain our technology is.
And maybe you're doing your one millionth Java application.
You're pretty close to certainty.
Maybe you are doing you first closure application, the way over on the right now.
We've never done that, we've ever built anything like this.
On the vertical axis what we're showing is how far from agreement we are on requirements.
Do we know what were building?
We are building a simple address book.
There's bunches of these out there.
We know the requirements.
we can copy them from other products.
That would be low on the vertical axis.
Are we doing something novel, something that has never been done before?
or at least not by us.
We'd be high up on that vertical axis.
So what we're looking at here, if you map these two, we can see the projects that have a lot of technical uncertainty, a lack of agreement on the requirement
side is going to be in the top right there.
Right?
Probably nothing's going to work there, right?
You've got a lot of technical uncertainty.
You're not even sure what you're building yet.
The best thing to do is get some certainty around one of those two things.
Before you build the world's biggest, scariest, most novel closure application, get experience with the language, all right,
or prototype something so you know what it is you are building.
Move out of the anarchy region in one direction.
Let's go down to the bottom.
Down in the left bottom there we've simple.
This is right in a simple address book.
Done it before.
Same technology.
You can be successful with other processes here.
Scrum can't be okay, but it's not going to get you huge benefits there.
Where Scum is particularly helpful is what are called the complicated and complex regions in there, where we have fair amounts of both technical uncertainty.
This can tough.
I don't know how we're going do this.
And I'm not exactly sure what we're building.
We've got a vision, we are headed out here, but we have to see what our customers say.
Those type of projects, when there's a fair amount of uncertainty, that's where Scrum is going to have its biggest benefits for us.
That's what most of our projects are too, especially in the software world.
So let's look at what Scrum is all about.
And by the way, if you have questions at any point, just raise your hand or signal me in some way.
I'd like to take questions as we go.
We keep kind of scanning back and forth.
You've got this weird, long, skinny room.
So I keep trying to see if we have any comments or questions.
If we do, please raise you hand.
So let's see what Scrum looks like.
Let's build up a Scum process diagram here.
We're going to start out with something called our product backlog.
This is that prioritized features list.
Now suppose we're gonna build an e-commerce website.
I've got a couple of features I want to add to our site.
we've had a basic site up.
Where no Amazon yet, but we got to basic sight going.
And we'd like to ad to this return, gift wrap, and cancel.
Those are the features we want next.
Our product owner prioritizes those features for us.
The team is going to make progress against those features in sprints.
These are the one to four week time periods I mentioned.
At the start of a sprint, the team has to figure out, what are we going do?
And so the teams gets together and has a meeting to discuss the product owner's priorities.
And they select some amount of work off the Product Backlog.
In this case, I've only selected one item.
A team will almost always grab more than one.
For graphical simplicity, I'm just grabbing one item here.
Makes the picture easier.
So in this sprint, our team has decided we will deliver returns.
People can return a purchased item.
I don't like this book.
Sending it back.
All right.
Hope I didn't read it first.
To do this, we have what we call a sprint planning meeting.
The sprint planting meeting is where the team selects the amount of work to do.
In the sprint plan meeting, the teams creates what is called their sprint backlog.
A sprint backlog is a list of tasks necessary to deliver the product backlog.
Now here's something I wish we hadn't done in Strom.
I really wish that we had done this.
We've overloaded the word backlog, product backlog, sprint back log.
There's two, okay?
There are two.
Product backlog big visible features.
Look at the things up there.
Cancel, gift wrapping.
All right, return an item.
Those type of things, big visible things.
Customers might see those.
The sprint backlog is tasks.
It's going to be things like design the UI, all right?
Code, test, create some test data, automate this, have a review meeting with the customer about such and such, those type things those will be our task list,
our sprint back log.
At the end of the sprint, the team comes out with something we call potentially shippable product increment.
Basically, what we're talking about here is finished, done, tested, working code.
Some feature is done.
And we put the word potentially there to indicate that we do not need to ship this thing.
We may not release this at the end of the sprint, the ended the couple of weeks, but we could if we wanted to.
It's high enough quality that could.
So what were after here something that's, high quality, potentially shippable.
One of the things that appealed to me about Scrum when I first started to learn about this is that Sc rum takes essentially a two-faced approach to change.
Scum says no change in the sprint.
No change in the sprint.
What we're trying to do there is allow the team time to focus.
So the Team doesn't have to be always looking over their shoulder going, things are going to change.
I shouldn't make this big change on the code.
They're going change direction on me.
And I know I'm about to get interrupted.
Right?
So we want to create an environment where the teams can focus, but we know change happens.
We have accommodate that change, so we let that happen at the level of the product backlog.
Meaning, if our product owner comes up with new ideas, hey, let's take vouchers.
Let's offer voucher on our e-commerce website.
That comes in as a new feature idea, new product backlog item, and the product back log is sorted putting vouches in where it belongs.
So change happens outside the sprint.
We lock the Sprint down, letting the team focus on what it is they're building that Sprints.
One last thing I want to toss in up here, me in the top middle, I'm going to talk in our daily standup.
Daily stand up, this is where the team gets together, 10 to 15 minutes a day.
It's limited, no more than 15 minute, and they talk about it.
To synchronization, it's not a status meeting.
Status meeting always sounds, well first it sounds boring, second it sound one directional.
I will give my status report to the project manager.
You won't listen while I give my report.
And then while you give your report, I won'l listen.
That's a status meeting.
This isn't a statistics meeting, this is a synchronization meeting This is team members talking to each other.
Here's what I'm doing.
What are you working on?
Anybody stuck?
We go through things like that, trying to keep the project on track.
So that's it.
There's nothing else to scrum but what's shown up here.
By the way, somebody asked me this morning why I was qualified to talk about Scrum.
I didn't want to start with my bio-slide or anything this mornin' because we're time-pressed, so I don't wanna bore you with background.
But somebody did ask why i was qualifed to talked about scrum.
So, here's why.
i have a scrumb tattoo.
l have that picture on the wall on me.
so if I'm tattooed with scrumm, I feel qualified talk it.
Those of you close enough can tell that is a fake scrum tattoo.
At the end of our session today, help yourself.
I got a bunch of scrumb tattoos up here.
So if you're at all bought into this, grab some scrumm tattoos on the way out.
And I don't want to fly them home to the US, so take as many of those as you want.
Oh, I hate going back to animated slides.
But I just want pause here in case there are any questions on that, because this is kind of the whole framework in cases brings up any any question anybody
has right now.
OK.
Let's get through our animation here.
I want to talk about sprints, these one to four week time boxes where the team is making progress on the project.
By far the most common is a two week iteration.
My recommendation here is to find a link that works for you and stick with it.
Do not bounce around.
Don't go two weeks, one week, four weeks.
Three, two, to two.
One, for two don't bounce.
Around find the link.
That works.
For you.
And stick.
With it A lot of factors influence our sprint length.
Sometimes it's things like how long our product owner or business can go without changing their minds.
All right?
Sometimes, it is how quickly we need to deliver things to the market.
So think about pick a length that works for you.
It's not a life sentence.
You can change it a few months from now.
If it isn't working for ya, change by all means.
But don't bounce.
Don't balance around.
That rhythm is beneficial.
I don't like four-week sprints.
That's our maximum.
Calendar month is our max.
We end on the 18th.
Very few people do that.
Some people will do a four week sprint.
Every four weeks, we start a new cycle.
I Don't Like Four-Week Sprints One of the reasons I dont like 4-week sprint is it leads to thinking like this.
Oh, We got 4 weeks.
Let's use the first week for analysis.
Design the second week.
Code the third week, and we'll test the fourth week And that's not what we want to do on a Scrum project.
On a Scrum project, what would like to is to have a little bit of everything happening all the time.
There should always be some design going on, always some coding going.
Now in different amounts, we're not going to be doing most of our coding the last day.
At least I hope not.
But we wanted to balance that out.
We're in the analysis phase of the sprint.
And when we go to a really short sprint cycle, teams figure that.
You've only got a week.
You're not going to have a day of analysis, a design, and a coding.
So teams will figure that out with the shorter sprint lengths.
Longer sprints tend to get tempting to introduce phases into our sprint.
It's not a good thing.
Talked about no changes.
No changes in a sprint.
This slide is just kind of repeating that.
What we're trying to do here is to create an environment where the team is allowed to focus.
I remember it was about two weeks ago.
Before I left on this trip, I'd left the office.
I went home, and I was still trying to get some writing done.
All right, books.
And so I still try to do some riding done at home.
But it was starting to close to dinner time, And I could hear my wife banging around in the kitchen.
Dinner's getting ready.
So I don't want to start on the new article I have due, because it's almost dinnertime.
Don't wanna get my head into the article.
and so i replied to some email.
Read a couple documents.
Okay, play a game too.
And dinner should be done by now.
It's only 45 minutes, you know, they're banging around.
My wife's a good cook, but it's not like she cooks things that take hours to cook.
So I was like, dinner's got to be ready by know.
And so I go ask her, what time are we eating?
And she said, oh, not for another hour.
Our daughters had longer dance practice or something, so they weren't going to home at the normal time.
What had happened here is I'd let all that time escape because I kind of feeling this, you know, constant, oh, I'm about to be interrupted for dinner,
and so I didn't get productive.
I just kind let that time slip away.
So we're trying to create an environment where the team does not feel like they're about be to interrupted.
You've got two weeks, so i will not change my mind on you.
Go build gift wrapping or vouchers or whatever it is we've chosen to do in that sprint.
We try to leave the teamwork alone, let them focus, create that environment for them.
The Scrum framework is made up of three things.
We've got roles, and we have three roles on a Scum project.
And we've ceremonies, activities that happen on our Sc rum project, And artifacts.
So what I'd like to do is to dive into these roles and ceremonies and artifacts Let's start with our three rolls.
The first role on the Scurm project is that of product owner.
Our product owner is our key business representative, kind of the key stakeholder.
This is the person who is often funding the project or who represents the users to us on the product.
Product owners are responsible for the Product Backlog, for making sure the Project Backload is in the right order.
product owners also responsible from making what I refer to as scope schedule trade-off decisions.
Scope schedule trade-off decisions.
Here's what I mean.
We're sitting here in early June.
And we're thinking about it.
Should we release in September with that much functionality?
We can have that by September.
Or we could have much by October.
September, October, September October And so our product owner makes that scope versus schedule of trade off decision.
When would be the right time to release?
Early with not as many features, later with more.
So they're the one who makes those type of decisions for us.
One of the nice things about Scrum We don't need to decide that today.
Some of us do.
But others of can wait until maybe August.
And in August we'll decide, OK, we're pulling the trigger in September.
It's going to be September release.
Or we might get to August and go, yeah, our competitor didn't release their product.
Let's skip September, We'll go to October, and we really have a bunch of features in there for our customers.
So often we don' have to make that decision now.
At the end of the sprint, the product owner is shown by the team what they built.
And the Product Owner accepts or rejects each of product backlog items.
The Product owner can look at it and say, I love what you did with return.
That's fantastic.
Vouchers, we got to go back.
We got make some changes to vouchers.
So the Project owner accepts and reject the work of team at the ends of each sprint.
Now, I often think of the team as a race car.
That makes sense.
The team's job is to go as fast as they can.
So the teams a racing car, the product owner is the driver of their racecar.
They're the one aiming the car at the right goal.
We have another role on a Scrum project called a scrum master.
You might have heard about this role.
It's got a weird name.
Scum Master.
Now we've got this scrumm master role, I think of the scrm master as the mechanic for the car.
The scrmm master's job is to have that car as tuned up, as ready to go as possible.
So the Scrum Master helps the team go as quickly as they can, but not necessarily in the right direction.
That's the Product Owner's job, to get the Team aimed in right directions.
So we have Product Owners, Scum Master, and Team.
Often the one who is supposed to know Scrum the best, they're the ones that helps the team use Scum to be successful.
They're one that might make decisions like how long our sprint should be.
When I first started hiring Scrum Masters, I started doing this in 1995. We didn't have the title Scum Master.
So I needed to hire people to effectively do this job.
I just called them project managers back then, but they were a very different type of project manager.
And I told them their job was to be bulldozer and shield.
Bulldozer and shield.
They were a bulldozier.
Any problem in the team's way, get it out of the way.
That's your job.
You're a shield, you're there to protect the Team from any sort of outside distraction.
Later we started to think about the metaphor of coach for Scrum Master.
So I also think of a Scum Master as a coach.
Somebody there helping the teams on to their best performance.
And we think a about a Coach on a sports team.
Scrum Masters are a coaches.
There to help the Teams be the best they can be.
The third role is team.
Team.
Only three roles we have on a Scrum project.
Product owner, Scum master, and team, typical team size five to nine people.
I hate putting a number up there, though.
If I have to do it, if I didn't, you would ask me that.
How big should a team be or can it be?
Five to 9. For me, that does include the product owner and Scumbaster.
Five the nine.
But I don't like putting the number here, I like instead how Amazon does it.
Amazon talks about their teams as being what they call a two pizza team.
A team they can feed with two pizzas is the right size.
And I like that as a way to think about our team size, by the way, if you're hiring, that's me and one small tester.
Some days, a very small tester.
So as silly as that is, I think it's the right way to think about our team sizes, right?
And I'm not picking on any food allergies.
I've got my own.
But if you have a big team, you're not going to remember what people can eat and don't eat or like to eat, things like that.
If you've an eight-person team you know how many pizzas to order.
And you remember you got two people who are vegetarian.
All right, if got a 23- person team How many vegetarians do we have again?
And is he still gluten-free?
I mean, it's too hard.
It's to hard, right?
So if ordering lunch for the team is hard the teams too big.
I think that's the Amazon lesson.
And 5 to 9 a real good sweet spot for our Scrum teams.
Scum teams are meant to be cross-functional.
They're meant have everybody we need to go from idea to implementation.
Everybody we need from idea to implementation, we can take a product backlog item and fully implement it.
Meaning that team will have programmers and testers, maybe database people, and maybe UI designers.
UI's not important though, at least that's what I heard this morning right now.
Some teams it is, some teams is not.
Now you're doing more of an API team or something.
But we're going to have everybody on that Team necessary to go from Idea to Implementation.
I'd like most of those individuals to be full time.
that I've got the word should up there.
I know in today's world, we're not always going to have everybody full time.
But the more we can do that, the better off we are going be.
Self-organizing, we touched on this.
We said there is no one person, no tech lead, who gets to assign out all the tasks.
And then the last one, I mean, barely worth touching on here.
Memberships should change between sprints.
It's just too confusing for teams if you're getting new team members in the middle of the sprint.
So we try to put any team member switches should happen at the spring boundaries.
So those are our three roles on a Scrum project.
Let's touch on the four ceremonies of Scum.
Four ceremonies.
We've got one called Sprint Planning.
One called sprint review, another one called a sprint retrospective, and then a daily Scrum.
So let's start with our planning meeting.
The other three meetings in Scum are very short.
Very short, this one long and painful.
This is going to be a few hours.
Some teams will take a whole day to do this if they have a long sprint, complex project perhaps.
Most teams have got this done in two to three hours, but some teams'll spend longer.
Everybody attends the team, the scrum master, their product, or the whole team is going to be there.
That's going be a consistent theme across all four of these meetings.
The agenda is for the teams to talk about the top of the product backlog.
Remember the Product Backlog, our Prioritized Features List.
We don't talk but the Whole Thing.
The whole product backlog, there may be stuff on there we're never going to do.
There may stuff further down in that prioritized list.
We're not going do for six months.
But we are going come together and talk about the top items.
What might we do this sprint?
What's a little bit beyond this?
Maybe we can get it in.
So the team will talk the about top of the product back log.
They select what to do.
That is a really important bullet point.
The team selects what do do, the product owner does not tell the team.
No, the team selects how much they can do.
Teams are empowered to select the amount they could do, now they should be motivated, they shouldn't go, we get to choose,
okay, you know we'll just do that much.
The team should do as much as they, but it's up to them, nobody gets to say you have to do eight items or you do one fourth of the backlog.
The reason why we do this meeting is to feel like that what we are going to do has been talked about in enough detail that we understand it well enough
to have a chance of succeeding with it.
We come out of this with two things.
I mentioned the sprint backlog.
Sprint backlogs can be a list of tasks.
Spring goal, just kind of a one-sentence summary.
It gives us a once-entence-summary we can use to describe to outsiders, your boss's boss wants to know what you're working on.
That becomes our sprint goal.
A one sentence summary of what we're doing.
The way this works is we come together, the whole team, product owner, scrum master, and team members, And the team looks at the top of the product backlog,
They read that backlog item and they say, OK, what do we have to do?
They create the list of tasks.
Most teams will estimate those tasks, so that's going to take six hours, that can take four hours.
Mostly breaking things down into the kind of four to 10 hour range, most tasks They commit to one item, they grab a second item.
They break it into tasks, estimate the hours.
Commit to it.
The grab 1 third.
And they keep breaking these things down.
Now this is called a sprint planning meeting, but I think the meeting is a little bit misnamed.
Because it's not just a planning meetings, it is also a design meeting.
the team is doing technical design in this meeting the Team is Doing Product Design in This Meeting.
See what I mean here.
We're in this meeting, and the team says, how should we handle this error?
What should do if the user types in that?
The product owner says wow, I'd want you to do this, we've got to make sure this doesn't happen.
That's product design.
It's also technical design, when the time is making their list of tasks, they're talking about things like, wow should this in the middle tier?
No, no, we got to do this in the UI.
It's got be more responsive than that.
Let's do in this the JavaScript.
And so this is a technical design, a product design and a planning meeting all three together.
One of the reasons it takes a long time.
That's also the reason I don't get too frustrated when it's taking a lot of time because it is us there designing the project.
Designing the feature at a high level at the technical and product level.
It's our sprint planning meeting.
Longest, only real painful meeting on Scrum.
The shortest meeting of Scum, the daily Sc rum.
Here is where we get together once a day.
for 15 minutes maximum, not guaranteed minimums, 15 is maximum.
And we talk about how things are going.
This is a chance for team members to synchronize their effort.
It is not a problem-solving meeting.
We're not there to solve issues, we're there just to discuss things.
Now it's very common for the team to hang around afterwards, maybe half the time, and solve a But we don't mandate that the whole team has to stay there
to solve some problem that came up.
We just kind of raise issues, discuss things.
All right.
All I came across is, so we're just a little bug yesterday, but I got it fixed.
I recommend everybody change this parameter to your JVM.
Something like that might get mentioned.
Others are like, I'm really stuck on this.
Can somebody pair with me for a half hour today?
I just need to talk it through with somebody to figure out what's going on.
So we talk through issues like in this meeting.
The meeting is...
meant to be for team members only.
All right, now we allow others to talk, but it's meant, or we'll allow other to attend, But it is meant only for the team to members talk during this meeting.
And you might be wondering why I got those weird chickens up on the screens.
Let me explain the weird chicken up there.
There's an old joke in the Scrum world.
You gotta know this old jokes if you're gonna be anywhere near Scum.
The old is this, there's a chicken and a pig walking down the street.
When the chicken decides, let's start a restaurant.
Let's start a restaurant.
What do you think, pig?
And the pig says, that is an intriguing idea.
I'm a very entrepreneurial type of hog.
And I am sick of working for the farmer.
Let us do it.
But the pigs says what are we going to call the business?
What are going call to the restaurant?
The chicken says let's call restaurant ham and eggs.
The pig said no thanks, I would be committed.
You would only be involved.
Not the funniest old joke.
Not the funniest old joke, but a very common joke in the scrum world.
And it is meant to point out the difference between that chicken who just lays an egg or two, and the pig who lays down his life to be part of the breakfast.
Now, nobody likes to call a chicken or a pig, so I'm gonna beg your permission to let me refer to people as chickens and pigs for the next 60 seconds or so.
Because here's the idea.
The idea is that team members are committed.
They're pigs.
Is a pig?
The Scrum Master is committed.
There's debate.
Sometimes there's a debate about the product owner.
Is the Product Owner committed?
Are they a Pig?
Or are they just involved, or are just a chicken?
Well, here's the answer.
The early days of Scum, the 90s, Product Owners were chickens, and we were happy to have that.
But the 1990s model of Product owner was somebody who showed up, said, Here's what I want, I'll see you in a month.
And they came back in the month and they told us if they liked it or not.
What we've learned is it's a much better model to have a committed product owner.
Somebody who is a full-on team member, somebody who's there not necessarily every day, but somebody is there at least mentally with the team during the process.
So, today's world of the product owners are pigs, they are committed team members, and they're allowed to talk in the daily scrum.
But, your CEO, I'm generalizing here, assuming your C.E.O.
is not also one of your best programmers, Your CEO shows up at the Daily Scrum.
We tell your CEO, ooh, sorry.
Please be quiet for a few minutes.
Will finish our meeting.
And then we'd love to hear any questions you've got for us.
But let us get around the room and do our Daily scrum first.
In going around, the we answer three questions.
Each team member answers three question.
What did you do yesterday?
What are you going to do today?
And is there anything in your way?
I touched earlier that these are not status reports.
These are team members sharing information with each other.
Let's look at the other two meetings.
We've got a sprint review and a Sprint Retrospective.
Similar meetings, very different in terms of what happens, but similar meetings in this sense.
is about inspecting and adapting on the product.
We look at the products, we inspect the project, and we adapt.
we make changes.
Customers aren't going to like this.
Oh, wow, customers love this new UI we've added on this part of the application.
Let's go do more of that.
So we expect and adapt on a product The retrospective, We inspect and adopt on that process.
We talk about how Scrum's working for us, and we make changes to the process.
So the review, we inspect and adapt on the product.
It is a demo.
The team demonstrates what they've built.
Now, this takes very different forms in different companies.
In some companies, were demonstrating to product owner.
And other cases, the project owner is demonstrating outside stakeholders.
Typically going to be up to an hour long meeting.
I don't want this to go much longer than that.
It's a hard one to predict because if you're doing longer sprints, you are doing stuff that's very UI intensive.
You can have a longer sprint review than a team that is building a commercial API into something.
Everybody's got an opinion on colors and user interfaces.
So those type of meetings will take longer.
So this is the review, we're getting feedback.
We're looking for things we should change.
In the retrospective, were looking things for we change in the process.
Were talking about how is Scrum working for us?
And we might decide Scum's fantastic, but not those four week sprints.
Let's go down to two week sprint.
Nah, I think three week is better.
Lets go to three weeks, let's start with that.
Or I thinks Scums doing okay for but our product backlog items aren't detailed enough.
We're coming into the sprint with just something that says cancel an order.
That's not enough detail.
We need a little more detail before we start.
Let's find a way to add detail to our product backlog items.
Or maybe the other way around, we've got too much detail in our backlog.
So in a retrospective, were looking at ways to improve the process.
My favorite way The retrospective is just in what we call a start-stop-continue meeting.
We have the team come together and say, what should we start doing?
What should stop doing, and what shall we continue?
So not very touchy-feely here.
I don't really care.
Ooh, how do we feel?
No, no.
What are we going to change?
We're very action-oriented.
What are we going to start doing?
What we're going stop doing.
So we are focused on things very directly actionable that we can change in the sprint.
Lots of other ways to do a sprint retrospective.
This is just my preferred way to this.
Let's look at our artifacts.
Product backlog.
The product backlog, I mentioned this earlier, is the requirements list on a project.
It's prioritized by somebody called our product owner.
And the idea with the product backlog is that each item in a product back, I always kind of think of it as an Excel spreadsheet when we bring one up.
Each item and the project backlog should be valuable to our users or customers.
Each item should be valuable to our users or customers.
Now, if you've heard of something called user stories, a couple of these are in the form of a user story.
Probably the second, third, and fourth I would say qualify as essentially user's stories.
User stories are short, simple statements told from the perspective of the user.
As a traveler, I want to be able to book a room in this hotel.
As a traveler, I want to be able to specify the type of bed in my hotel room, something like that.
These are short, simple statements that a user might have for our system, in that case, the travel system.
In this case I'm showing a product backlog along with an estimate.
Next artifact is something called a sprint goal.
Sprint goal, just a short summary of what we're trying to do in that sprint.
One or two sentences.
And again, this is where I said earlier, This might be for your boss's boss.
You park, you get in the elevator, You push the nine button, and your bosses boss gets in, And your Boss's Boss says, What are you working on this sprint?
Well, your boss doesn't want to hear your whole sprint backlog.
Oh, I got to code this.
I've got design this, oh, we got a UI review on this and they don't hear that.
They don' even want hear all of the product backlog items.
they want a short one or two sentence summary.
Something like this Well this sprint we're working on basic shopping cart functionality.
Things like add review and update quantities.
A couple weeks later, bad timing, you get in the elevator with the boss's boss again.
And the bosses boss wants to know what you're working on now.
Well, he got another sprint goal.
You say, well, this time we're workin' on the checkout process.
Things like paying for an order, picking, shipping methods, things like that.
So it's a short one or two sentence summary that we can use for outsiders, outsiders of the sprint.
Next artifact.
Oh, I actually want to stick with managing the backlog here for a minute because I want show you a sample one.
The sprint backlog is always meant to be an up-to-date reflection of what we have to do.
meaning it's never complete.
We're going to do a sprint planning meeting, and we're gonna write the sprint backlog.
But we are not going think of everything.
In fact, I don't even want you to think everything, but I want to you think fairly hard, come up with all this easy stuff you can.
Don't stay in there forever thinking harder and harder, making that meeting longer than it needs to be.
Do a good job, think the stuff that you and then let the Sprint Backlog evolve.
New tasks will show up, you'll re-estimate things.
That's harder than I thought, that's good because this one is easier than thought.
So anybody can add to the sprint backlog once the sprints starts.
Any team member who discovers something.
So the key point here is that work emerges.
This whole idea of emergence is a very common thing with Scrum.
The product backlog emerges, we don't have the whole thing.
the Sprint Backlog emerges we, don' have everything identified on there.
So here's a sample sprint backlog.
We walk out of the sprint planning meeting.
Let's say we're doing one this morning.
You'll notice that coding the user interface, about half done.
Took that down from eight hours to four hours.
Middle tier went from 16 hours, to 12 hours We finished up the online help system.
Our tech writer had a good day yesterday.
Tech writer didn't work 12-hours, but did get to cross out a 12 hour task.
Had a real good productive day, and our techwriter finished that whole task Wednesday, watch what's going to happen on Wednesday.
Especially the bottom there, I added a task This is where we discovered a new task.
I forgot error logging.
We didn't think about that during the planning meeting, so we added it on Wednesday.
The other thing to notice there on wednesday is look at the top row.
Coding the user interface got harder.
I worked on it all day yesterday and it went backwards.
It's going to be harder than I thought.
Back to eight hours.
So the idea here is that the sprint backlog just represents our best guess at any point in time of what we have to do and how hard it's gonna be to that thing.
And then Thursday and Friday.
Sprint backlog looking something like this.
Another artifact out of the scrum process is something called a burndown chart.
This here is a sprint burn-down chart.
This is real one.
It's a team outside of San Francisco, California.
And you can see up there in the top left, the very first point is around 780 hours.
These guys were doing a 20-day sprint.
Those are dates on the bottom.
I should have changed those to be more European-style dates.
Just didn't think about it.
Wasn't looking at it The first day of that sprint, they had 790 hours of work.
The second day, They had more work They had a productive day.
They worked all day on Monday.
But when they added things up on Tuesday, they had noticed two things.
New tasks.
Things like error logging on that earlier screen.
Oops, new task.
And tasks they have identified got bigger.
So those two thing conspired the first couple days to send their backlog up.
Look in there at about 16, 17 days into the sprint, you'll see a big drop.
The dropped 200 hours.
Now that's a good day!
Well, except they dropped the 200 hours, they didn't actually make 200-hours of progress.
They dropped a product backlog item out of the sprint.
That moved them a whole lot closer to their goal.
So with the Sprint Backlog, all we get to see here, the sprint burndown chart, is how far the team is from the goal?
I don't know if that was a good or a bad thing, we just see where it is.
And they made progress there, but not in a great way.
Here's a sample of making a sprint burndown chart.
We add up the work.
Get a new dot, we put that dot on the chart.
The next day we add up the work there.
Put a dot new on a burn down chart, so each day, day by day were putting these new dots onto the burn-down chart this is something I would expect Scrum
Masters to be doing the Scum Master will do this in a minute or so a day.
A lot of tools will this do in an automated manner.
Not a big fan of the tools, they get in the way for other reasons but a tool does make this part of Scram a whole lot easier.
But hopefully adding numbers up isn't the hardest part in doing Scrom.
That'd be nice if it was.
Scrum Scales.
I've worked on a 560 person Scum Team.
And I've consulted two, three, 1,000 person Scrum projects the first time I said that, I say team.
No one is on a 560 person scrum team, right?
Imagine 5 60 people standing around in a circle trying to get a daily Scum done in 15 minutes.
All right, the point with that is that Scums scales up by having teams of teams, all right.
We don't get one big team we have teams teams.
So we're still going to keep our Scrumb teams in that seven to nine range, maybe a little bit bigger, Don't go too big.
Remember, we're going to cut the pizza slices too thin.
But maybe a little bit bigger when you have a 500 person project.
You're gonna have 10, 11 person teams more than the six person team just because of the hassle factor of having that many teams.
So a number of things will influence how we scale this up.
One of key things in scaling up is a meeting.
If you've heard about Scrum, you might have heard of this meeting, It's got a very catchy name.
I don't think this meeting is as important as its name is catchy.
So here's the meeting.
The idea is to do what is called a scrum of scrums meeting, picture each of those blocks of team members down there doing a daily scrump,
the little 15 minute meeting right now.
Imagine this is something like Microsoft office.
This makes Microsoft Word.
So I've got three teams working on Word, but you know what?
Word is one product.
I want to have one person from each of the Word teams come together and talk about overall Word issues.
All right, so we got 3 teams on working Word but let's pick one from those Word team, have them get together maybe twice a week,
and have another meeting.
We'll call it a Scrum of Scum of Scrums.
A third level would be a scrum of scrums.
And these are coordination meetings that we use to coordinate across the multiple teams on a larger project.
This is just one of the things we do to scale ScrumUp.
I think a more important thing we to do scale ScrumUp is this.
We call this a community of practice.
What I'm showing here are just our three Scrum teams.
What want to do is I want have conversation cut across our Scum teams, face it, I need the programmers talking to each other.
So we set up this thing called a community of practice, which is a group of like-minded or like skilled individuals.
And so I went to programmers, talking each to other, this might just be a shared discussion list, a little shared email list.
Maybe it's a share email in a monthly meeting.
Maybe it's a weekly lunch that the testers have.
The DBAs, our UI designers, are scrum masters as well.
the point here is to have ways to communication cut across our scrumm teams.
These communities of practice help us do that.
I'm not going to focus too much on this, just here's a list of books that are on Scrum in a significant way.
I've got a book on estimating and planning Scum projects.
We've had sessions on that later today.
Clinton Keith has a great book, on agile game development with Sc rum.
This is actually the best book to go into all the technical practices.
So if you're a programmer, tester, really looking to understand Scrom, let me skip testers for a second.
If you are a program, you really want to learn Scram and the practical practices, real good book.
I know Esther Derby is here tomorrow.
Agile testing.
This is why I said skip testers for a moment.
Here's the right book for testors.
Agile Testing by Lisa Crispin.
Coaching Agiles Teams by Elisa Adkins.
This is a book on all the soft skills for Scrum Masters.
All the ways to coach your team to the best performance they can.
Essential Scum is coming out next month.
Succeeding with Agile is my book.
Don't buy that book first.
That's kind of a second book on Scrum.
It goes into all the specifics.
Not a good starting point, but a great second on Scrum.
And then User Stories, I don't know if they have that out there, they might, is about the product backlog.
As I mentioned earlier, this presentation is totally available for you.
It's up there in PowerPoint in Keynote format.
Please take it, make it your own, use it to convert your companies, your friends, user groups, whatever you want.
Um, it's been translated into 23 languages, so go ahead and grab the, uh, kanji version and impress your boss with your,
you know, multilingual skills.
Flash up the Romanian version, just go, whoops, I was working on my Romanian over the weekend.
This is up there on my website, which is mountaingoatsoftware.com.
You'll find presentations up here, including this one in that format, plus a ton of other presentations.
They just asked that I put this in here.
I've got classes coming up on Scrum here three and six months from now.
And there's my contact information.
I'm around all day today.
So I am fair game any time for other questions.
And I've got a lot of other sessions on Agile.
Hopefully this one kind of piqued your interest.
Again, grab some Scrum tattoos because I don't want to have to fly them home to the U.S.
Any questions before we wrap up?
Get you guys on your way to next session a few minutes early.
One is based on the product backlog.
I know you have a separate session on it, but my understanding of it is more higher level user stories.
But let's say you had bigger tasks, such as if it's an existing software, so you need to do some major refactoring or not visible.
Right.
First question is how do you get those into the project backlog?
Okay.
If you have a small team and you also have running soft system so you get all this immediate bug fixes and all these things that will affect the team,
how can you best...
OK, two real good questions.
So the first question is, what do we do about stuff that's not really kind of new feature oriented in the product backlog?
Refactoring, cleaning things up, things like installing a new version of Windows or new Linux servers, all that type of stuff.
The product back log is meant to represent anything we need to do to get out a successful product.
Those type things do go on to the project backlog as well.
I think if we went back to the example product backlog I had up there, I'll just flash back there while I'm talking, the sample product back log I have
up here had at the bottom of it an item that said to improve exception handling, a purely technical thing, this would be some sort of refactoring thing.
We could change that into a user story that was user focused if want.
As a users I'd like errors handled in a more appropriate manner so I don't see a bunch of Java jumped on top of the screen or something like that.
So I do think those type of things are totally appropriate on a product backlog.
Sometimes we do have an issue with the product owner, having to convince them that those are worthwhile things.
Some teams will get around that by somewhat agreeing with their product.
Look, we're just going to keep a certain amount of our time for ourselves, for technical cleanup things, other times I'll meet teams that'll say,
We have a hard time convincing our product to allow us time refactoring.
All right, so here's my advice on how to get your product owner to allow you time for refactoring if they're not letting you do that.
Go to your project owner and make the same arguments about refractoring that you made when you convinced your products owner that need time to compile
your code.
probably didn't have that discussion, did you, right?
It's just part of doing a good job.
I have to compile, assuming I'm a compiled language, I gotta compile my code, so that's not the product owner's business.
That's me doing good a job, me writing good code is just me doin' a god job my product doner doesn't get to tell me about that.
Now when I something that gonna put me out of commission for three weeks while I refactor a huge chunk, okay, now we gotta have a conversation.
But all those little things that are just about doin a God job that I not gonna going to have a discussion with.
In terms of how do we get a team to protect the team's time if they're working on a new version or a big new set of features,
and they are also doing support on the current version that's out there, here's how I think about this.
I'll grab my water bottle here.
The first thing that you pour into the sprint is corporate overhead.
It takes a certain amount of time to be a good employee here, So I got a pouring corporate overhead.
The next thing is planable time.
That's how much time the team has that's their own.
Then I have unplanned time, unplan time goes to tasks I don't identify, tasks that get bigger than I thought, now both of those are kind of my fault,
but they also go to interruptions, servers down, Mike, please go fix it.
So I have to leave some room for plan of unplanned time up here.
Now let's hypothesize two teams here, one team is two people in a garage making their first iPad game.
Not a lot of corporate overhead, right?
Corporate overhead for them is, hey, you order the pizza today, all right.
Lot of planable time, not a lots of interruptions.
So they have a lotta time that's their own.
Now, hypothesize another company in a big bureaucracy doing second level tech support on their shipping product.
They have lot less time it's there own So when they go to plan their sprint, they will have less time available.
When we think about things like, and I think we've got one coming up here shortly, when we thing about thing like their burndown chart,
what I'm saying here is they would not start up as high vertically.
They wouldn't have as many hours at the start on that first day.
So, okay.
Thank you guys very much.