Transcript
We asked me to do this keynote a couple months ago, and I asked him what he wanted me talk about.
And he said he want me introduce Agile, to kind of explain what Agiles all about, but not to give a typical, you know, here's Agil,
heres a this, hers a that.
Introduce it in a little bit more informative way.
Because we are certainly going to have people who already know what agile is about and so I want to introduce the concepts behind agile.
Concepts under why it, the advantages to it.
So there's going be A different way of doing it though, I want to do it by describing what I would consider the sins of project management,
ways that we can go wrong on project manager.
A lot of different Agile processes though.
There's the ones listed up here, the one's that I consider Agil in the top box here.
We've got extreme programming and Scrum, very similar to each other, a few differences.
We've got Crystal, a family of processes, another one called DSDM, LEAN, kind of an approach, not necessarily a process on its own.
My favorite, Unbranded Agile, which is just kind taking the best of these things, combining them in a way that makes sense for you,
getting rid of all the brands, my preference.
And then we've got some that I would consider semi agile processes don't get into a lot of debate about why I wouldn't consider them agile the biggest
reason for me the one reason that i would concern them some I agile is that they don' t rely on self organizing teams self organization is a fundamental
principle to agile and these processes actually.
Some of them great processes, and I've seen all of the work.
I actually seem them work more often than I have seen them fail, the bottom ones.
So I do like those processes but I wouldn't go as far as to say they're agile.
Just wanted to put that up there.
In terms of kind of getting started before we get to what the sins are of project management and how those help us, I want to just kind zoom in on Scrum
for a minute.
Describe what Scrum is just for two slides, so we have a starting point.
Then I'm going to jump into the sins of project management and how Agile helps address and resolve those.
Through the way, I am going pull in some case study data, show some examples of teams that improved in terms of going faster,
teams have got much higher quality as a result of being Agil.
So Sc rum.
One of the things I like about Scrum, no engineering practice is prescribed.
I find it difficult to introduce an agile process to an organization and say, hey, we want you to be agile.
We trust you solve the problem.
You're smart.
Go figure out how to solve this business problem, by the way, you have to do it exactly this way and then prescribe a bunch of specific engineering practices
or other things.
So I want the process as lightweight as possible, just a framework.
Scrum fits that bill, so one of the nice things about it, no specific engineering practices.
Scum teams use what they call sprints.
A sprint is the same as what most of us would call an iteration.
I met one client about two years ago, I was in a meeting with them, And they're talking about, oh, in a sprint, we do this and that.
And 10 minutes later, somebody would say, In an iteration, We do such and such.
This went on, it's meeting for about an hour.
Finally somebody said, well, when we're in sprint we this, but when in iteration we that?
I got very confused, I kind of perked up from the meeting, and it was like most meetings I'm starting to doze off.
I said wait, wait wait.
Sprints and iterations are the same thing.
What are you talking?
They said oh no no, they are completely different here.
What's the difference?
He said, well, in a sprint, we're working overtime.
In an iteration, were doing the sustainable pace thing, trying to work at a long-term sustainable place.
I was like, you know, interesting, I mean I could totally buy that as a distinction.
And I said well how long have you been sprinting?
How many of them have done?
And they said we were in eight months of sprint.
I'll use both terms today, sprint and iteration, same thing.
Fundamental to Scrum, self-organizing cross-functional teams.
Scum gets its name from the play in rugby, European sport, ball is put back in play, the way it's put in back play comes from having some of the bigger
players on the team with their arms around each other, pushing against the other team.
That's meant to represent the cross functional team If you look at the, there's five books out now on Scrum, three in English,
two in German.
They're all small.
I think every one of them is under 200 pages.
One of the reasons for this is that there is not a lot of rules to Scum.
There's a lotta, in any of Agile really, There is a lots of kind of behaviors and techniques and principles and values, not lot a rules.
The few rules that we have tend to be what we call generative rules, rules we put in place to generate the right behavior.
For example, Scrum will have a daily meeting.
We ask teams to get together and talk once a day and we recommend three questions that they do.
I don't really care if they got together and asked those three questions or three different questions.
Those three question happen to be ones that we found that generate the right type of behavior on teams.
They get the discussion at the level.
Not too high, not too deep.
So generative rules to create the behavior we want rather than a big lengthy rule book like we might find in a more prescriptive process.
In Agile, in Scrum, we're going to have a set of players that looks like this.
We're gonna have team.
This is not meant to be a hiring list, just a representative list of the team members.
Or you have somebody called a Scum Master, other processes or companies might call this an iteration manager.
They might called it a coach or Agil coach.
There's persons there to enforce the process, the values of process.
Not the, you know, did you ask the right three questions, right?
Team can deviate from that, but are they following the value of a process?
And I've got up there the metaphor that they're a sheepdog.
We use that in the Scrum community to represent the idea that the scrum master or coach is there to protect the team.
One person the scummaster often protects the teams from is somebody called a product owner.
Product owners are on the business side.
They're always pushing for more.
That's a good thing.
I want them pushing their teams for for.
A good scrummaster can look at that and say, hey, productowner, back off.
The team's little burnt out.
And see them making a few mistakes.
Back off a little bit for a couple weeks.
Let the kind of catch its breath.
Also, a good scrum master, though, might say, hey, product owner, while the team's not listening, let me tell you, now is a time to push them.
They're feeling pretty recovered.
I think this team is ready for more.
Push them a little bit harder.
So we've got this kind of partnership between the scrumm master and the product donor looking at the process and one looking the at product.
Last slide kind of showing what scrum's about, then we're going to dive into these sins.
Just to get this started.
So on the, on a scrumm process, we have a thing called a product backlog over here on left side of these screens.
This is from a kind a hypothetical e-commerce site.
We will say we've got an eCommerce site up.
we want to add three features to it.
That's our product back log, prioritized by our Product Owner.
The team works in a series of sprints.
They tend to be two to four weeks long.
Those are the most common links.
At the start of each sprint, the team gets together, figures out what are we gonna build.
And they look at the prioritized backlog, they pull one item off that backlog.
Maybe multiple for my graphics, my limited graphic abilities.
I just wanna pull off one items.
So the teams says we're gonna work on returns this sprint.
They select that based on the product or its priorities.
Then they determine what they can do by looking at it in task level.
Take these items, break them into tasks, and figure out where we can commit to.
The team decides this print we could do these This one task, this one feature returns, we'll break it down into five items.
Code this, test this automate this.
Validate the other.
They create tasks like that and they make their commitment.
At the end of the sprint they try to come up with some working software.
Something potentially shippable, not truly shuppable in all cases, but done, something that's finished.
One of the things that appealed to me about Scrum, it's got a two-faced approach to change.
No change inside the sprint.
Nothing allowed to changes inside that sprint, however, the whole world can change outside the Sprint.
Here we're showing coupons.
We've decided to offer $20 off coupon, 10% off coupon, things like that.
Product owner adjusts the priorities on the backlog, moves these around, puts coupones in the proper place.
Last element to add up here, once a day the team gets together, synchronizes their work.
This is not meant to be a status meeting.
This was not a meeting for the manager, scrum master, coach, or iteration manager.
It's the team getting together and talking about it.
I suspect many of you, even if you're not on Agile teams, have done that meeting, I'll touch on that more a little bit later.
Here are the sins that I want to talk about today.
We'll talk the sin of gluttony, and we'll see what that is.
And I wanna talk my favorite being in Vegas, Going to open space and hooking up with people.
We'll talk about sloth, we'll about opaqueness.
That's a sin.
The sin of pride, the sin wastefulness and of myopia.
So we will talk those seven sins.
Let's look at our first one here.
the first sin is gluttony.
I probably should have taken a picture of the buffet at the restaurant in the hotel here too instead of this big hamburger.
Gluttony refers to trying to get too much, fixing all the dimensions of the project, saying I want all of this, I wanted by this date,
and of course I need a high quality level.
When we act as gluttons on our project this leads to schedules that we're not going to make, it leads the death marches,
the eight months of sprinting, eight month of overtime.
We end up cutting quality.
Project Management Institute draws something they call the Iron Triangle.
You've all seen this, I'm sure.
We've got scope, schedule, and resources on the sides of the triangle.
With the idea here, you hear this described different ways.
If you go to your customer and you say, pick two, or you can't walk down all three, choose any two parameters, then I can make the project successful by
fiddling with the third dimension.
One of the questions that Agile tries to address is, which dimension is the best one to fiddle with?
By the way, we've got quality in the middle because quality is of course fixed.
We don't ever fidle with quality, right?
Never see that happen.
So what about resources?
Is resources a good lever to pull on to achieve success?
Suppose we're heading towards the end of a project and we are not going to make it.
We're going be late.
Can't deliver everything on time.
Well, one way to possibly meet that deadline with that set of features, add more people.
Well, very unpredictable.
It might work, it might not.
There's the whole mythical man month concept, there's Brooks's law, adding people to a late project only makes it later.
So even if we thought this was a good idea, its very risky.
Might work might now, might be a horrible thing to do.
What about schedule?
We can pull in the schedule lever.
We're headed towards the end of a project and the team says, if just had a few more weeks we'd be okay.
Technical perspective, it's a pretty good solution.
A couple more weeks, a little more work, we're done.
From a business side, maybe not such a good idea.
We've got marketing commitments.
we've lined up trainers to go train our user base.
All sorts of reasons why schedule may be a bad lever to pull on.
Scope, from a technical perspective pretty, good drop some features.
Maybe not so bad, as long as the team, two things are true.
The team has worked in priority order and as well as a team did their best work.
As long the was not screwing around or doing bad things, long they worked on priority orders, scope not such a bad thing to drop.
So on Agile projects, we favor scope management.
We do this in a number of different ways.
One of the ways we do it is through time boxes.
Time boxes help teams avoid gluttony.
We treat the iteration or the sprint length as fixed.
We say here's what we're going to get done.
Now we may float the number of iterations that we are going run.
we start out thinking maybe we'll be done in eight two-week iterations.
Partway we realize maybe it's going take us nine or ten.
I have two iterations to get enough functionality in to make coupons a valid feature.
That's our budget.
I know I can get at least something credible in in two sprints, and we work in priority order at the end of two sprint, we're done with coupon,
so we move on to the next thing.
This helps us avoid grabbing too much.
Time boxes also help us with predictability.
Over time, a team is able to figure out how much they will complete.
We call this velocity, really kind of their pace per iteration.
There's a real team up there, nine sprints.
You'll notice that velocity is volatile.
It's not consistent.
I used to try to make this point by tossing up a graph of a team's last 82 sprint.
and showing the volatility over those 82 sprints.
The team I tossed up was the Chicago Bulls back when Michael Jordan was with them.
They call their sprint games, but that was a very representative graph of what a team might get.
Volatility in velocity is normal.
It's part of we would expect.
So we're going to look at things like average velocities and such.
Let me show you one way that this helps us avoid gluttony.
Suppose we've got a project that has planned something like this.
We've planned to do those first four features in the first sprinter iteration, the next four in next iteration.
And we got some estimates that go with these.
These might be in what an ASL team would call story points, maybe ideal days.
They're just a relative size for now is all we need to know for today.
We've estimated those.
This team would have a planned velocity of 16. If you look at those numbers, we've got a 5, 3, 5 and 3 in the top, that adds to 16, this team has a plan
velocity 16 They run their first sprint though, and when they run that first, they end up doing this.
They only get the first 3 done in that sprint.
they have an observed velocity 13. This team has to set some expectation going forward of what their velocity's gonna be.
They've gotta be communicating out to bosses and customers and clients where they think they'll finish.
So think about for a moment what you think their likely going-forward velocity is going to be?
Well, one argument might be 16. That's what we've done historically.
Something told us to setup 16 as our velocity in that plan on the left, so let's go with 16, A valid argument for that.
Maybe that's our average over the last 10 years.
On the other hand, maybe 13's the right answer.
This is called yesterday's weather.
Let's plan on this iteration getting done what we got done last iteration.
Valid argument that, so there's a valid for 16, there is a valed argument 13. I don't know which is right, I'd have to be in the context of this project.
What about the argument 19? We have get back on track.
Is that a good answer?
Which one do we tend to choose on traditional projects?
I think we often tend choose 19. Got to get back on track.
Looking at it this way, looking at with these velocities, and when a boss comes to you and says, you guys got to back track,
or worse, when we're tempted to assume that ourselves, oh, we'll get on back.
We learned a lot.
We have something that told us to use 16 past history.
We just experienced a 13. There's no logic in choosing 19 as a going forward velocity.
By all means, try to achieve 19. Try to get back on track.
I am not saying not to.
Do try get to back track, but when you have to set expectations with people, they better be somewhere between 13 and 16. 19 would not be a realistic number.
That would be deceiving our customers.
Now I've got two choices when we get down all the way to K and L.
I can drop those, or I could extend their lease, I do a fourth sprint.
It would be a choice that the team would have to make.
Let's go on to our second sin.
Second sin is lust.
Lust is an intense or unrestrained craving for features.
More, more, and more.
It comes from trying to pull in too many features during the time that we allow.
We see this on those projects where we'll have 95% mandatory features This leads to kind of violating that sustainable pace principle that we're after.
Leads to dropping quality then, either intentionally, oh, we've got to get more in, or unintentionally because we are working too fast,
and leads us to surprises.
How many bosses have you met in your life?
The first day on the job, you meet with your boss, your bosses, my primary rule is no surprises, right?
I think every boss I've ever had told me something like that, right?
I don't want to be surprised, that's a common thing.
Lust leads to this.
Now I got three ways I want touch on that Agile deals with lust.
The first, we focus on working in priority order.
Even if everything is required, even if we have a product owner that says, I need it all.
It's like a car.
I can't have car without four wheels and an engine and everything else.
Even we work with a project owner like that, an agile team has to work in order.
They take one item off the product backlog, they take the second, and they the third.
So there's an implicit, to some level, forced ranking of the items.
Okay, you need it all, Mr.
Product Owner.
Which one should I do first?
The team grabs the first four or five, runs a sprint.
This helps us deal with lust.
The second way that we deal Our lusts are incrementally gratified.
Every two to four weeks we're seeing some software come out.
This avoids letting lust accumulate.
It's kind of like a release for our lust.
Getting the opportunity, customers who get to see software every couple of weeks, very beneficial.
I used to have this theory, before I got Agile, I've always been pretty close to it, but before i really started to do it I use to had this feeling that
it took two to three releases for a development organization to be trusted by its customers.
And I was thinking this kind of in an internal environment.
This is where I worked a lot in the late 80s.
And, I always felt like my customers needed to see me put out a release one, then they needed give me feedback and I would do a released two,
and then I'd do release three, And then, they would trust there'll be more releases and this team will give us good software.
Now, that was back in era when those releases were six, nine, 12 months long.
I mean, it took two to two and a half years for the customer organization to start to trust my development organization.
Well, in Agile, I think it still takes two or three deliveries.
I don't want to call them releases.
But that can happen in the shortest two of three sprints now, right?
You hire me to write something, and I write to something and give it to you in two weeks.
And I do another one, give you two in three weeks, do you one more, two week later, you start to trust, oh, there's going to be more and you have this feeling.
So less doesn't build up.
A mentioned sustainable pace, so let's look at it a little bit more.
Big part of Agil is working at a sustainable place.
We asked how many Europeans we had here, or at least outside the US.
And I remember Kent Beck telling a story about how when he wrote about this initially and went over to Europe to speak about it,
he called it the 40-hour work week.
He went to over Europe and started talking about the forty- hour workweek as though it was meant to be a good thing, which it would be here.
So the Europeans got mad.
Why do I have to work overtime just to the agile?
37 and a half hour work weeks and things like that.
We can't change this and refer to it now as sustainable pace.
The idea here being that a team should work at a pace that they can maintain over the long term.
Little sprints, that's a bad term, but little bursts of extra activity may not be a useful thing.
I love this quote from Kent's second book, his second Extreme Programming book.
It says, over time is a symptom of a serious problem.
And it basically goes on to say, if you've got a problem that you can solve with one week of over-time, go ahead.
Sustainable pace doesn't mean 40 hours every week, it doesn�t mean 37 and a half hours a week.
Go watch a 10K this weekend.
Stand at the finish line.
You'll see what a sustainable pace is.
They speed up over the finish line, right?
Edge out the person next to you, beat your friend that you think is about 30 seconds behind, catch up with that one runner ahead of you.
That's not sustainable.
It's the last 200 yards, and people sprint across the end.
Sustainable pace doesn't mean exactly 40 every time.
Kent says do it one time, solve that problem, but if you come back next week and think you need to do that again, you got a big problem.
I've got this graphic of this scrum candy bar with less crunch down there, right, less over time.
Because one of my clients, the High Moon Studios, learned this the hard way.
They're a video game developer.
Video game industry is one of the few industries that has the great big industry trade show still, where everybody has to go and show off their software
for the last year.
And old habits die hard.
It used to be that when the trade shows would come up, everybody would go into overtime mode for a couple months preceding the show.
You wanted your publisher to like it, you wanted to start getting good press, and you'd put in a lot of overtime.
So here's a slide showing how High Moon learned what overtime does.
This was their normal velocity, this was our normal pace.
And I could have drawn this out over the last dozen or so sprints, their, This is their average velocity over their previous dozen,
or, so, sprint.
this team's running one week, one-week sprin at this time.
They decided, trade show coming up, everybody better work some overtime.
they put in some mandatory overtime, and of course velocity went up.
We're getting more done.
Let's keep at it, let's do overtime again.
Second sprint with overtime, they saw this.
Little bit ahead still, but notice the big drop, right?
Probably not worth making people work extra just to get that.
But we got some big benefit that first week, let's do it again.
Mandated overtime again, well now we're getting screwed, lets keep doing it.
What happened here, this is all very objective.
This was measurable.
If you talk to the CTO of this company, a guy named Clinton Keith, good friend of mine, if you talked to Clinton, his theory about what happened,
here is the team did get more done that first week.
Absolutely got more down.
By the second week, they're starting to get a little more tired, little bit more sloppy.
Some sloppiness crept into things, and that sloppyness came back to hurt them in the third and fourth weeks.
So, this to me is evidence that Kent Beck's suggestion, one week overtime, go ahead.
Now I don't know, I might be willing to extend that.
Hey, you've got to work overtime two weeks.
Go ahead, most people can handle that, but if you're looking at it as a chronic situation, eight months, the story I started with today,
it's not going to help.
This is the type of thing that I could put up eight different companies showing you this.
You still don't internalize it until you live through it.
Until this is your data, this really hard.
This why the old habits die hard, Clint Keith who led this company through this, he knew that overtime wasn't a great thing to do.
Still a temptation and it's free to try in most companies.
So we try it and here's what we see.
Third sin is sloth.
Most of you've seen this graphic, the roadkill paved over here or painted over.
The idea with sloth is it's kind of losing the focus on doing high quality work.
This often manifests itself as testing quality in at the end, or not needing to do quality, not needed to any testing.
Most of us have worked in the environment where the boss said we don't need testers, just hire better programmers, things like that.
I worked on one of those.
This leads to big delays, unpredictable schedules, variability in the team's velocity shows up.
If we have low quality work, we will see the velocity be very volatile in teams.
I've graphed that with some teams before.
Just want to give you one anecdote of a team where I saw this.
My company was in a process of acquiring another company.
And I went out to do due diligence on the technical side with the company.
And as I met the development staff, I was mostly talking to them, they kept using a phrase that I found interesting.
Because I'd asked them about quality.
It's a big concern of mine.
If we're going to buy them we are going inherit their code base.
I want to know if it's any good.
and I kept asking about the quality and test practices.
Every time I did they used a phase that kind of threw me for a loop.
They kept saying quality is baked into our process.
That sounds pretty good, right?
Quality is fundamental, quality is baked into what we do.
And after about the eighth guy said that over the course of the day that I was there, like eight hour a day, after the seventh or eighth person who said this,
I finally say stop.
What does quality as baked in mean?
I'm not getting this and everybody uses this phrase, where does that come from?
And the one guy came clean because I think he knew that if we went with the acquisition I'd end up being his boss and he certainly didn't want to lie to me.
And he came clear with it about what it meant.
Quality is baked in was a phrase that came from their CEO and it was basically the excuse to not hire testers.
We will bake quality into the process, we will write good code as we go, We don't need any testing at the end.
So this team did no testing whatsoever at end and we ended up not acquiring them.
So Agile takes quality very seriously.
Here are some of the...
You know, I should have changed the top of that slide to say XP practices.
These are really XP practice.
And one of the nice things with XP, XP being extreme, it's often out there in the forefront of new ideas.
Being on the fore front is extreme and risky and things like that.
But it is great because we get these extreme programming teams out their trying all sorts of things and then the rest of us can pull them into our projects.
So these are real XP practises more than agile.
I want to give XP the credit for coming up with these ideas But then we've pulled these into most agile teams simple design right trying to keep it simple
not getting to elaborate no more complex than it needs to be huge focus on automated testing I love this part of it test-driven development writing a little
bit of a test before you write some code.
I love doing tests during development.
I'm such a total geek.
My Christmas present to myself this year was four hours of uninterrupted programming time on Christmas Day in my home office.
And my wife agreed that would be her Christmas Present to me was to let me program for four hour uninterupted.
and I am working on a little project for my daughters who are on an age group swim team.
and I'm writing some new features for their website, and doing it in Ruby on Rails.
Not a language I am really great with.
I've been doing for a few years now, but not great at it.
Because I just learned it by kind of diving in, not going through a bunch of classes or real systematic study.
Just kind diving into writing code.
And I write everything test driven.
It's Christmas day, it's mid afternoon, I get to a part that I don't know how to test first.
When I think about it, And then I looked around the room, my home office, to make sure nobody would see me write code first.
And I cheated.
I wrote the code.
Then I went back and wrote a test after.
But my eight-year-old daughter was going to walk in and say, Dad!
Red, green, refactor.
You can't do it that way.
Continuous integration.
Always having a build server watching the code that gets checked in.
If we break something, find out about it now.
I look back and I can, I mean I laugh at how I used to do this and think we were pretty good.
We used integrate once a week.
Everything from all 20 programmers, we'd get integrated once week and that was so wonderful back in 91 compared to how we did it before.
That was wonderful.
Why we never thought, hey, if integrating once-a-week is so much better than doing it randomly, why don't we do it once day or once an hour?
I don' know why we didn't ever think of that.
I'm kind of ashamed I didn't.
Per-programming.
I invented per- programming, by the way, I know that the XP community thinks they did, but I did.
It was 1986, and I got hired by Anderson Consulting.
And on day one on the job, they had me fill out a skills assessment.
They said, how good are you at C?
And I was a rank beginner, a barely beginner.
Oh, intermediate.
By the time this big company reads this thing, I'm enthused about this language.
This language was the first one that I started to learn that fit how my brain worked.
Fortran and others didn't fit.
C fit with my Brain.
So I am going to Learn this.
And by the time they read it, I will be intermediate.
They read the next day.
That was Tuesday.
On Wednesday, they had me fly to New York from LA, where I lived, to new York.
They put me on a project in New york and I was there to write C code.
Fortunately, there was another developer that had been in the same situation.
Third day with the company, and they'd flown him in to NY.
And I talked to him and said, Chris, I gotta come clean.
I lied.
Im a beginner.
Chris said oh shit, i lied too.
We decided that by pairing up, they wouldn't know which one of us to fire.
He and I paired there for the next four years.
I left, I went to Sacramento, California and started a company there and brought him there.
We paired for four year.
So we paired from 86 to 94 most days.
Guy ended up being a good friend of mine, my best man at my wedding and things like that, all from pair programming.
Refactoring.
Agile teams go in and clean up code.
I grew up as a Boy Scout, and Boy Scouts always learned that weave the trail cleaner than you found it.
This is part of what refactored is about.
We coach teams.
When you go and if you see things that aren't perfect, if they aren�t good, just leave it a little bit better.
If everybody does that, things improve.
Let me show you a company that did this.
can't use their real name, so I'll call them CosmodemonicBioTech.
Any Henry Miller fans will catch that reference.
They had an existing product that had been built.
It was 3,000 use cases to build the product, and it took them nine months to do with a total of 540 person months.
Not a huge project, very rushed, a very complex domain, too.
This is a biotech domain.
Very complex.
An average of 120 lines of code per month.
Now, I'm not a big fan of lines and code.
We know if we set this up as a, you know, whichever programmer writes the most lines a code gets a bonus.
we know that's a bad idea.
But in hindsight, measuring a team that wasn't measured at the time, and it's probably a credible metric, so 120 line of codes per person per months,
this company got into a situation where they were essentially acquired, but the product was acquired and was assigned to a new staff to write a completely
different version of the project because the waterfall version had failed.
So a team wrote the same product.
This was a chance to compare different products with different staff.
Um, this product I got to, to run, I did it with Scrum.
We had 1400 user stories, fairly large project, took 12 months.
It took longer on the calendar, But we did with a much smaller staff, and I don't think there were ever more than six people on it.
It was 54 person months, which is conveniently I can do in my head, one-tenth the number of person-months.
A little bit smaller, I would take that to probably be a good sign because it actually did much more, and it worked, the previous one didn't,
with a productivity of what's almost Seven times more area seven times.
More So very successful this team did this by focusing on quality this Team had I should have put the number of test lines up here But I don't know it
for the waterfall team this had more than 51,000 lines of Test code they had More test code than they have production code and this is what allowed them
to go as fast so dealing with the the sloths in the second one this company here We mentioned Lisa Crispin, who's here, author of a wonderful book,
Testing XP, and a new book coming out, I guess, towards the end of the year.
This is her company.
So stop by and talk to her.
She can tell you more about this one.
Wonderful success here.
A product that was kind of struggling, way before Lisa was here, I'm not going to blame her for that, she came in and helped solve these problems,
and the company had to get good at Agile to do this.
And they had improve their quality, they were having production issues daily.
They got to the point where maybe a production issue once a month coming in.
So I looked back at what the team had done, and again, this team was not measured in terms of lines of code or anything during the time,
so I think it's a valid measure in hindsight.
U.S.
average that I dug up at the times was 270 lines per person per month.
This team has gone fairly quickly before that.
They averaged 389, but they did that by being very sloppy.
I mean, it was a buggy system initially.
This team, nine months after they started Agile, I measured what they had done.
They were about a little over three times faster than they'd gone before.
That was pretty impressive because certainly in the first month they weren't any faster, right?
So by the ninth month, they were going a whole lot faster.
Here is what they did in quality.
In the three years prior to starting with Agile, they were having 10 defects per 1,000 lines of code.
Pretty high.
And the first nine months after they started they had 2.9 defects, per thousand lines.
Still kind of moderately high, but there was no big rewrite of the old system.
I didn't have a way to go back in and see how many of those defects were reported against the old code versus the new, but I'm going to guess 80 to 90%
were still against old the code.
But that old had been gradually improved as the team went in, refactored things going through the system.
It's even better.
They did this without a targeted rewrite.
This improved just by the refactor and leaving the codes cleaner than they found it.
And if we'd measured the new and the old code, it would be even better.
I'd have a better number to put up there.
That's sin number three.
Sloth.
Sin number four, opaqueness.
Obscuring the progress, quality, or other attribute.
This, to me, is about not knowing where we're really at.
This is one of the biggest benefits that I see to Agile that the bosses report to, me.
An executive in a company or a product manager in the company, this is the part of Agiles that they love, that there's no longer this opaqueness to the project.
They get to see where they're at, see how Agil deals with opaceness.
So I want to talk about a couple types of opaconess, the first being quality opacuness.
With quality opaqueness, we don't really know where we're at in terms of the bug count and the quality of our system.
This is another place where time boxes help us.
At the end of every sprint, were supposed to be potentially shippable.
If at the of that sprint reiteration were not potentially shipable, It's a real bad sign, we better fix that problem.
So we don't get to the end of a traditional project.
We go for nine months and we're going to have the three-month testing phase.
But we have no idea if that's the right amount of time.
Maybe the team wrote high-quality code, maybe they didn't.
Well, with an Agile project we can avoid the 90% syndrome.
Things are done or not done.
No debate about it as we go through.
How we handle with schedule opaqueness is this.
Some of you may have seen a chart like this before.
This is what's called a release burndown chart.
A release burn down chart shows the amount of work that the team is doing per iteration.
This team here, it's a real team, planned to do 360 what we're going to call story points, just a measure of the size of each of items on their product backlog,
360 storypoints over four sprints.
They had a planned velocity of 90, they were going do 90 points per sprint.
The run the first sprint and they see that.
By the way, let me back up.
This is their hypothetical line.
Alright, this is the hypothetical, not the reality, I'm going to add on the real line here in a moment.
I draw the hypothetical line so that we can look at this.
In reality I don't normally draw this line, but I've drawn it today so I can put up their observed velocity and I could ask,
are they ahead or behind?
So look at that for a second.
Notice they're behind schedule.
They expected to be down to that white-blue line.
There at the diamond instead.
Tiny bit behind.
CEO is guiding adoption of Scrum into her company.
She'd read an article about it somewhere.
It's just fairly technical.
And she hired me to come train her team and get them successful.
Small company, about 100 people.
Not all in development.
Development is 20 or something.
Four sprints, I have to meet with her at the end of the first sprint.
We don't have anything useful to say, it's one data point.
I wish we were a little ahead instead of a bit behind, but one datapoint, no big deal.
Well, we ran the second sprint, what do you think we talked about there?
Linda, did you say firing me?
No, oh, okay.
No we didn't talk about firing and Linda didn' say that.
We talked about what now?
I drew the trend line through here.
It was 6.1 sprints.
And the CEO said, I can't wait six sprint.
I said well I got bad news for you.
In Agile, we round up.
That'll be seven sprits.
So there's no way I'm waiting seven sprint.
We told the sales people they'd have it in four.
Well, what are we going to do?
Well we could drop some work.
Look at how much we'd to drop there.
We wouldn't have to drop just down to the blue line, we'd have drop below.
She said, I can't do that.
I said well could you drop a little bit?
I think the first sprint was pretty representative.
Second sprint, second iteration, a bit of bad luck.
We're not going to have that again I don't think.
Think our true velocity closer to that first Sprint.
So if we dropped a litte bit maybe we could be done in five.
She said, I can drop a little bit.
I never believe it when somebody says that.
So I said show me.
Which ones are on the chopping block?
I want to know which items.
And she did.
Okay, let's plan on five sprints.
Let's not drop anything, but let us plan five on sprint.
We ran the third sprint.
Here I went and asked for big rays.
No.
Just like I shouldn't have been fired after the second, I should not ask for a big raise after third sprint.
Notice the first and third balance out.
Random noise.
Second sprint, some bad luck.
Here, CEO and I talked about how we may want to go in four sprints.
One more sprint like this third one, we'll be done in 4. We'd only have to drop a little bit.
She said, now I'm not going to tell people it's coming in four, we've already told them five.
If I tell them four I know it'll be late, it will be five, so let's just stick with five five looks very safe.
We ran a fourth sprint.
Kind of looks like Parkinson's Law took hold here.
Work expands to fill the time available.
No it didn't.
The team continued at the pace of number three.
But then they said, we're not going to do a sprint with that much.
Let's add some work, let's make it a decent normal sprint.
And they added enough work back in.
So if you can imagine this line drawn, they drew it down, erased it, added some scope back, and then redrew the line where it shows on this picture.
Then we ran the fifth sprint to finish.
Now, this is about showing real progress on the team.
I work with a lot of execs and they'll say this our favorite part of Agile.
Work with this one president of the company and he loves this.
He says, sometimes the news isn't good.
Sometimes it looks like sprint number two up there, but I always know where we're at.
And he had a VP and a past wife that lied to him and always told him, oh, we'll be done in one more month, one month.
And he says, you know, they can't lie to me anymore.
I know where we're at, and I can deal with it.
And I make decisions.
Here's scope-opaqueness.
So we've seen quality schedule, now here's the scope opaqueness.
This is the same graph we saw earlier, team over nine sprints.
Im interested in three things from this velocity graph.
Am interested their long-term average.
But I'm also interested, in their kind of worst-case average, how bad might things get?
I define worst case as take the worst three out of the last eight.
I don't care what this team was doing back in the Clinton administration.
It's way too long ago.
But what's their average over the eight sprints?
Their worst-case.
So I'm going to take their worst 3 sprits, average those up.
And I've got to do the same with their best sprint.
Let's take there best 3 chosen among the 8. You can use your own definitions, I don't care how you define these, it depends on how long your teams stay together,
depends how your sprints are, but something like this that lets you find your long term average in a best and worst case.
I'm after what a statistician would call a confidence interval.
But I do not have 100 items, or even 30 or 40 items in most cases, to go back and get a truly statistically relevant confidence intervals.
So I use something that gets me close enough that I can at least make decisions with it.
Here's how I'm gonna use this information.
Let's remember these numbers for a moment.
We got 28, 33, and 37. Take the 28. Your velocity, your low end velocity.
Multiply it by the number of sprints or iterations.
Count down your product backlog, those stacked up index cards there.
And say, hey, at our worst case, we'll finish here.
Do the same with your average.
But do the the best case.
This lets us make predictions.
We'd like to run an ad during the Super Bowl.
We would like an add featuring one of those items at the very bottom.
No, it's not going to happen.
This lets us look at our backlog and make decisions with it.
So use these interpolations of velocity as arrows pointing into your backlog to predict things.
I want to show you another visualization of the same type of thing.
we saw a burndown chart.
this is a new type a burn down chart What I've got going on here is updating the burn down once per sprint, just like normal,
and then stacking up the product backlog on the right.
The product back log is shown in priority order from top to bottom.
the most important thing on our e-commerce site were some mandatory returns features.
Once we were done with those, we wanted to work on gift wrapping, and then let's go back and add a little bit of fancy stuff to returns before we go on
to exchanges, some shopping cart improvements, something else, then eventually coupons.
So this is our product backlog, most important at the top, down, so it's kind of flipped over.
You'll notice the work is all done, right?
That's where we're at on the burndown chart is that Sprint 7, the last circle.
So I can draw a black line over showing where we're currently at.
This tells me what's done.
It's a way of dealing with scope opaqueness.
I get to show where were at, I draw those three lines, the 28, 33 and 37. Extrapolate, draw some velocity predictions and say,
worst case, we are going to get half way into the shopping cart features.
So if we're worried about, will exchanges be in the product?
Can we do exchanges on our website?
Yeah, that's gonna be safe.
We're gonna have to go slower than our slowest long-term velocity for that to be at risk.
It's a way of drawing conclusions from here.
Sin five, pride.
Definition here is thinking that we know everything.
I don't need to talk to anybody, I know every thing that needs to be in this product.
This leads to leaving out stakeholders and other types of users.
Results in a failure to learn.
Thinking that I now everything means that don I learn anymore.
Here's the scrum diagram again.
We saw this before.
Think about all the opportunities to solicit feedback here.
pretty much throw a dart and you can hit an opportunity to solicit feedback.
One of the places that I didn't even mention on here, what was the agile retrospective?
Over here on the right.
At the end of a sprint, the team runs a retrospectiv.
In that retrospect, they reflect on how is the process working for us?
Team does the daily stand up, opportunity to learn there, get feedback there.
All during the sprint, we can be showing the software to our product owner, to others getting feedback, there during this sprint planning meeting,
all over the place, opportunities for feedback.
Feedback leads to learning.
Another way to deal with this sin is in how we engage our users.
I'm a fan of using what we call user stories for our product backlog items.
This is one of the Agile books that I've written on user stores.
I love this as a technique for engaging users.
So a couple sample user story.
As a user I want to reserve a hotel room.
as vacation traveler I wanna see photos of hotel rooms so I can choose the right one.
I changed that.
The first story says as user, the second one says, as a vacation planner.
I'm here for business this week.
It's a palazzo.
But I didn't pick it.
Where's the conference?
My assistant booked my hotel room.
Oh, there's Jimmy Buffett concert you've got to come back for in October.
Any parrot heads will know what I'm talking about.
And so I am coming back for a holiday.
Then I will make sure I look at photos of hotel rooms.
Where do I want to stay?
I'll pick the right room.
Make sure that I've got a nice room or nice hotel.
Much more important on a vacation than a business trip.
One more example up here.
As user, I wanted the site to be available with 5-9 uptime.
Just wanted to show a non-functional requirement.
User stories can work for non functional requirements.
These engage our users because they can relate to this.
Stakeholders can get much more involved in this than they the system shall this, and nobody likes writing or reading those.
Use cases, we might have made them a little too complicated for most users.
We take these user stories and progressively refine them.
This is a real example from one of my clients, a company called JDA Software.
They have a little over 500 people doing Scrum in two cities in the US, one in India.
Um, they sell software to large retailers, marketers.
So like Nordstroms or Walmart or any of those type of places.
The add a large user story as a vice president of marketing.
I want to review the performance of historical promotional campaigns.
Ads.
Where should I put my ad money is what they're trying to figure out.
It was a huge user story.
That was okay at the start, but as that story gets closer to the time we're going to implement it, we can break it up.
Then we broke it into a story about selecting the timeframe to use, another story selecting which type of campaigns to see.
I'm only interested in electronic advertising.
And I am not interested print advertising, I have a separate budget for print advertisement.
We can take these stories, we can make these even smaller if we need to.
This engages our users not just at the beginning, but throughout the process.
So user stories are a good way for dealing with this sin.
Next sin, wastefulness.
Misuse of critical resources.
Time can be misused, resources can misuse, right?
Motivation, team excitement can get misused.
Here's four ways that Agile deals with waste.
I'll toss up one more in a moment.
We time box things.
Again, time boxes can be used as budgets for features.
Were not going to let time get away from us because we're going be able to say, look, this feature is worth four weeks.
Let's put one four-week sprint on this feature.
We can have something credible for coupons in four weeks, and after that, we move on.
I know we'd like to spend six, maybe even eight weeks on it, but in the grand scheme, looking at all the features we like get,
it's only worth four week, so I think we can get something in at least four.
Time boxing keeps a focus on demonstrable progress.
Time boxes can let us know if we're building up bug debt.
Are we not finishing high quality work at the end of sprints?
It lets us measure that.
The daily stand-ups.
Anybody remember Fred Brooks' answer in the mythical man-mouth?
He was the first project manager to ever be a year late.
I remember reading that book, not when it came out, but a little bit afterwards, and he was asked, how can a project be year-late?
And he asked like it was impossible.
How can this possibly happen?
Yet most of us these days have worked or seen or had a friend work on a product that was a years late, right?
Most of can point to some project that is like that, or most us run an OS that's a You can't see but I'm on a Mac.
He was asked, how can a project get to be a year late?
Anybody remember his answer?
One day at a time, right?
The daily standups help with this.
I am firmly convinced of this, and I thought this even before I started doing Scrum, it's a long time ago, that projects slip by the frequency with which
they meet.
So if a project is meeting daily, of course it can be late.
But that day, the slip will be measured in days.
If a projects gets together and does monthly meetings, let's do a big monthly meeting and that's all we do.
That project might be laid, but it'll be measure in months.
The daily stand-up keeps the focus on things.
Now I said earlier that I bet that most of you, even if you haven't been on an Agile project, may have done a daily Stand-Up.
Let me explain what I meant by that.
You've got three weeks left on a project.
Your going to be on time.
That's been going on for maybe six months, nine months.
You're going to be on time, as long as everybody stays focused.
As long nothing slips through the cracks.
And somebody comes up with a great idea.
Somebody says, hey, let's meet every day after lunch outside the boss's office.
Or let get together in my cubicle.
There's a lot of space in MyCube right after a lunch.
Let's just talk for five or ten minutes.
And maybe somebody sticks up on the wall a list of things that have to get done.
And I come in and say that I'm struggling with something.
Somebody help me out.
I just can't get the vendor to call me back.
Can you call the vender while I am trying to the code fix?
We just talk about things like that every day and it feels very energizing and keeps the issues very visible.
What a great idea!
And we finish the project, we ship the product, and we start the next project and throw that good idea away.
Why do that?
It's a good idea.
Keep doing it all the time, even at the beginning.
It may not be as critical, but it's still very, very helpful.
So on Scrum, we do these throughout the project.
Iteration retrospectives.
At the end of a Sprinter iteration, We reflect.
We look back and we see what can we learn from this process?
I mentioned it now before I forget about a wonderful book on this called Agile Retrospectives, right?
Check that out at The Bookstore.
Sure they'll have that wonderful Self-organizing teams.
Self organization doesn't mean chaos.
It doesn' mean randomness.
The first book that talked about Scrum came out in 1990. And it describes the process.
Nobody had done it on a software project yet.
the authors are basically saying, wouldn't it be great if somebody did this on the software product instead of a new product development project,
like a tangible thing like the Walkman.
So it described it, it's very chaotic sounding, and the author go on to say, But control is absolutely exerted over this team.
It says it, but it's subtle and indirect.
Its in things like, who do you put on the team?
How big a challenge do give the theme?
Do you the put the teams co-located or spread out?
All sorts of things that.
So it is a subtle, indirect control.
I don't mean control in some sort of pejorative manner.
I'm just trying to point out that self-organization, letting the team solve the problem, does not mean chaos.
We still exert some influence over how that team will choose to self organize.
Another way we deal with waste.
We keep the intensity up.
I've got a good friend named Todd who loves Agile, loves Scrum.
Took him a while to get there, took him couple years before he really liked it.
He does these days, has for a couple of years now.
But every now and then he'll comment on how he misses the good old analysis phase where he had no deliverables for three months and he just sat in a room
and thought.
He's an architect, right?
And he's half joking.
I mean, he is half serious, too.
He really does miss that phase.
Because he also does somewhat miss Todd's, and he was like some of us, I'm sure, not like me.
But he the type who really did like the end of a project, where we're living there till 10 o'clock at night, eating pizza and soda and Mountain Dew and
stuff like that.
And this is the kind of intensity variance that we'll see on a waterfall project.
Pretty casual, let's go out for the really long lunch today, and hey, we'll make up for it at the end when we're living here.
Well, on a Scrum project, or Agile project in general, the intensity is going to differ over time.
It's going be more like this.
A two week sprint, yeah, you'll feel a difference.
Four week sprints, a little bit more of a different.
I'm the type of guy, I get on the treadmill at the gym, they get the nice gym here, go on a treadmill.
I set it at one speed, set at it flat, and I go that speed that time, the whole time.
Right?
I don't do the hill route and all that type stuff, right?
But I like how agile spreads these things out.
Todd, if I ever saw him on that treadmill, he'd be the sprinting, walking, going up the hills.
He likes that kind of difference.
So, find the right balance for your team.
Something that keeps the intensity level where it feels appropriate for the team I wanna show one example of one team that I think's done a great job with
this and how kind of spreading out the intensity level helped them quite a bit.
Salesforce.com.
These guys did a big bang agile transition.
They converted the whole company overnight.
The called me up in October of 06 and said, hi, we're Salesforce, We just converted 250 people to Scrum yesterday.
Can you help?
And I said, oh, come on, this is one of my friends playing a joke on me.
Who is this?
You know, a consultant dreams of somebody calling up his AI.
We got 250 people overnight.
And this, no, we're serious.
I say, OK, well, you don't need me, need a shrink if you converted 250 over night.
Here's some statistics from what they saw.
61% faster to major releases with almost twice as much functionality.
Real simple metric, the third one.
Number of features per developer.
Yeah, of course features were of all different sizes, but developers were all of different skills too.
Just a real simple metrics, it tells something helpful.
Increase in major release cumulative value, this is an interesting metric that needs a moment of explanation.
What they did here is they tracked how long each feature was available to customers in the year.
So a feature delivered in January was more valuable than a future delivered December.
How long did customers have the features that they got?
And based on that, they had tremendous increase in value.
The last sin, myopia, not seen beyond the current work, what you're involved in.
We see this in teams that don't see the big picture.
And we see it in individuals who get tied.
Here's my role, I only do my thing.
This leads to unsuccessful projects and delays.
In Agile, we plan at different levels.
We make release plans.
Here's where I wanna be in six months.
Even a team that puts out software every two weeks, true software out on a website every 2 weeks should put together some sort of release plan saying,
hey, in 6 months, here's what we want to add up to.
Each time we start a new sprint iteration, We get together and we planned the next 2 to 4 weeks.
So we're gonna plan it at a different level.
Right?
We deal with myopia by having cross-functional teams.
I mentioned I'm on a Mac today.
Steve Jobs was interviewed in Time Magazine two years ago, and he told an interesting story.
He was asked, how can Apple so consistently innovate great products?
Think what you want about Apple.
Not always a successful financial company, although recently quite a bit.
Very innovative, but most people will grant them that.
A very innovative company.
And he was ask, How can apple so concisely innovate products.
His answer was interesting, he answered in the form of a story, Think about a car company.
Car company comes out with a new car design.
They show it off at the car show.
People look at it and go, ooh, ah, beautiful car.
And Ford takes that feedback back to Dearborn, Michigan, and they tell the engineers, build this car!
People loved the design!
And the engineer's look and say, it's obvious why they loved design, its stunning!
It won't handle though!
We have to extend the wheelbase.
We had to change the rake of the windshield.
And the engineers apply some engineering compromises.
When they're done, they hand it off to the finance people.
Finance people look at it and say, oh, beautiful car.
Oh, and well engineered.
But we can't sell it for a profit.
Let's slap on the old tourist doors.
All right.
Well, let's reuse some parts.
And Jobs continues and says, why do this?
It says at Apple, if we're coming out with a new product, we get together a cross-functional team.
Why design a product that you can't engineer?
Why engineer a project you cannot sell to profit?
Get together across functional teams.
So we want to do that on agile projects.
But does this make everybody a generalist?
The last concept I want to talk about is kind of a myth, or what I'll call a water fallacy.
A mistaken belief about Agile is everybody needs to be a generalist.
So let's talk this for a moment.
Actually, you know what?
It's getting late, so screw this.
Let's, let' talk lunch.
I'm hungry already.
See, we got three choices of where we want go to lunch?
Let's skip the lunch here.
I'm sure it's great, but let's go to one of these three delis I saw nearby.
We've got McConeys.
It's a little Italian deli I've saw near by.
They only have one order taker, though.
But behind the counter, they've a bunch of sandwich makers.
Or we could go our second delie choice, Bruno's.
Completely different.
they got nine people working the counters, But only one person in the back making the sandwiches.
It's very different.
Or our third choice, we can go to Ferentino's.
Let's see what they have.
They've got four people working the counter, four making sandwiches, and five who can do both.
I remember my obligatory stint as a teenager.
I worked at a fast food place.
And I could make the sandwiches, I can take the orders, but I couldn't replace the register tape.
A few of you in that situation, right?
The little red stripe would start to show up on the tape, and I would have to call for Nicky, my manager, who knew how to replace register So I wasn't
the best at either job.
I'm sure the people that made, I was at a Mexican fast food place.
Um, i was sure that the People that were back making tacos and burritos all day were faster than I Was.I was pretty good at it.
My burrito tasted as good as theirs, but maybe they were Faster at wrapping things up.
So in answering the question of does everybody need to be a generalist, of course not.
But where would we rather go to lunch today?
You go Mcconey's, you're going to wait forever just to get your order taken, but your sandwich will be instant.
Afterwards, we go Bruno's.
It's going be the opposite.
If we got to Bruno,s we're gonna have no time at all.
There's gonna be bunch of people to take our order, it's just gonna take forever.
I won't even get my sandwich till tomorrow.
I'm going to go to Ferentino's where they've got this balanced out.
Not everybody has to be a generalist, but a few that can do multiple jobs go a long way.
So no, we don't need to take that absolutely brilliant database person and make them do something else.
Let them stick with the database.
I have a people that float.
It always surprises me that the sandwich shops have figured this out so easily, and yet we've struggled with it.
generalists.
I'm done.I want to thank everybody for their time and have a great rest of the conference.
Thank you.
