Hardening Sprints
Nirmaljeet M
Hardening Sprints. The question is specific to fixing defects from
previous sprints that have been added to the Product Backlog. Will
these defects get fixed as part of the hardening sprint? I have been
getting conflicting answers from multiple quarters so thought of
bringing this up in this forum.
Regards,
Nirmal
Ron Jeffries
wrote:
You will get varying answers. Here's the correct one. :)
It's simple, really. If a hardening Sprint is necessary, then the
preceding Sprints were not producing Done software.
Any form of specialized Sprint is evidence that the team's
definition of Done is not solid enough and that lack is acting as an
impediment.
Prosecution rests.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
I could be wrong. I frequently am.
Mauro Botelho
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
Nirmaljeet M
To be specific, we are currently in a planning phase and the primary
objective to ask the question about hardening sprint was to understand
if it is something that one should plan for. Obviously this is not the
case looking at your comments.
On Mar 16, 7:50 pm, Mauro Botelho <ma...@e-botelho.com> wrote:
> Ron is correct, as always :)
>
> Did you look into why bugs are not being found and fixed during the
> iteration?
>
> I've seen cases where a hardening iteration is needed for things like load
> testing, 3rd party integration tests, etc. I don't think I've ever seen it
> as a bug fix iteration though.
>
> Mauro
>
> > scrumallianc...@googlegroups.com<scrumalliance%2Bunsu...@googlegroups.com>
Michael James
BTW, when you did your Sprint Review Meeting(s), did your PO declare the defective items were "done"? Or were the defects actually new scope discovery?
--mj
> To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
Fuchs, Anton
Of course it is the aim that there's no bug in a sprint release due to
Q&A being done, etc.
Nevertheless, there'll always be bugs and I saw it a couple of times
that developers had to deal with a situation like yours. Sometimes it
was best to have a "bug fixing sprint". Sometimes it was good enough to
just fix those within the sprint. We just had a long discussion in
another thread on this.
Toni
> scrumallianc...@googlegroups.com<scrumalliance%2Bunsubscri
> >>> scrumall...@googlegroups.com>
Dan Rawsthorne
However, I think a Release Sprint is often necessary as a specialized
sprint. You only load the truck once, you only train the help desk once,
you only deliver the software and train the users on the functionality
once, you only issue the big press releases once, etc...
As far as code goes, everything should be good to go all the time. As
far as product goes, parts of it are only done every so often, and as
far as release activities go, many of them are only done once. Take a
look at my blog, http://blogs.danube.com/release-sprint
Dan ;-)
Dan Rawsthorne, PhD, CST
Senior Trainer/Coach, CollabNet
draws...@collab.net, 425-269-8628
Ron Jeffries
wrote:
> In, general, Ron, I agree. Specialized sprints are often smells.
> However, I think a Release Sprint is often necessary as a specialized
> sprint. You only load the truck once,
How many trucks does Amazon load every day?
> you only train the help desk once, you only deliver the software
> and train the users on the functionality once,
How many new features per year are you releasing?
> you only issue the big press releases once, etc...
How long do you want to wait for customers to get benefit so someone
can write a press release?
> As far as code goes, everything should be good to go all the time. As
> far as product goes, parts of it are only done every so often, and as
> far as release activities go, many of them are only done once. Take a
> look at my blog, http://blogs.danube.com/release-sprint
It's possible to work that way. I'm not sure why one would prefer
it.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
It's easier to act your way into a new way of thinking
than to think your way into a new way of acting. --Millard Fuller
Dan Rawsthorne
not wrong. Etc. Your quote was "Any form of specialized Sprint is
me. Thank you. I've also inserted some comments below...
Dan Rawsthorne, PhD, CST
Senior Trainer/Coach, CollabNet
draws...@collab.net, 425-269-8628
Ron Jeffries wrote:
> Hello, Dan. On Wednesday, March 17, 2010, at 1:55:23 AM, you
> wrote:
>
>
>> In, general, Ron, I agree. Specialized sprints are often smells.
>> However, I think a Release Sprint is often necessary as a specialized
>> sprint. You only load the truck once,
>>
>
> How many trucks does Amazon load every day?
>
Less than one per order. I'd guess one every 2-3000 orders or so...
>> you only train the help desk once, you only deliver the software
>> and train the users on the functionality once,
>>
>
> How many new features per year are you releasing?
>
I'm not. I'm coaching. But my teams are doing 3-4 releases a year...
>> you only issue the big press releases once, etc...
>>
>
> How long do you want to wait for customers to get benefit so someone
> can write a press release?
>
How much do you want to confuse customers with discussions of what
they're getting 3 months from now?
Ilja Preuß
> However, I
> think a Release Sprint is often necessary as a specialized sprint.
For some meaning of "necessary" I guess that's true. Mostly I think
it's "necessary" when we choose to work in way that makes it
necessary. And it sounds like it would always create waste in terms of
big inventory.
> You only load the truck once
Trucks are *so* last century...
> you only train the help desk once,
How often does Google train its help desk?
> you only deliver the software and train the users on the functionality once
How often does Flickr deliver software? How often do they train their
users? (Hint: http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr)
> you only issue the big press releases once, etc...
Perhaps big press releases, that are bound to a big release, are a smell, too...
Cheers, Ilja
Ron Jeffries
wrote:
> Didn't say I'd prefer it. I just said that it's reasonable. That it's
> not wrong. Etc. Your quote was "Any form of specialized Sprint is
> evidence that the team's definition of Done is not solid enough and that
> lack is acting as an impediment." I disagreed. And now you agree with
> me. Thank you. I've also inserted some comments below...
I agree that it is done. And stand by my statement that it's
evidence of insufficient Doneitude.
>> How long do you want to wait for customers to get benefit so someone
>> can write a press release?
>>
> How much do you want to confuse customers with discussions of what
> they're getting 3 months from now?
Not at all ... nor would I want to wait three months for my
customer, and my company, to reap the benefits of something
done today.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
To Fly, Flip Away Backhanded -- Master Frisbee
Dan Rawsthorne
development, but rather a function of the business...
Dan Rawsthorne, PhD, CST
Senior Trainer/Coach, CollabNet
draws...@collab.net, 425-269-8628
joseph....@gmail.com
You should have a definition of done. The only really good definition
of done is "live at the end of the sprint with zero defects and
perfectly aligned to what the internal and external customer wants."
All others are imperfect. Still, you must start with a definition of
done that you can actually do on day 1 in a sprint timebox.
A bit more also needs to be said, in my opinion.
Some people can interpret what Ron said to imply, if you have a
"hardening sprint": "Na, na, na, na, you don't really understand
agile." This is not what he meant (well, not always).
Now, some (most?) so-called hardening sprint are utterly stupid and
should have stopped long ago. The idea that bugs "ought" to be kept in
a list is stupid. The only good number of (known) bugs is zero.
Still, it is possible that you (or the team or the group) understand
agile, scrum, xp perfectly, it is just that you have impediments and
you haven't been able to remove them yet. So, you are doing a
hardening sprint until you remove those impediments. While not "good",
this is not evidence of utter stupidity.
Also: I have seen a few special situations (I don't think there are
many) where, when I looked at the situation, I wasn't sure that they
could ever do away with a "hardening sprint." It had to do with the
expensiveness of the test equipment, the fact that it was software and
hardware, etc, etc. Nonetheless, this does NOT mean that they did not
have plenty of impediments that they still *could* remove. They did,
and they could have been yet more aggressive about removing those.
So, to me, the first ideas are: "Whatever testing we do in the Sprint,
we will do it very professionally, and not allow any identified bugs
to escape the sprint." Bad news does not get better with age.
The second idea is: "We will never, never, never, never become
complacent about removing impediments until we can at least go live at
the end of any sprint." (eg, without a hardening sprint). (Note: Going
live does not have to occur at the end of a sprint, but it is easier
to think of it that way...).
As Yogi said: It ain't over 'til it's over.
Thanks, Joe
LeanAgileTraining.com
joseph....@gmail.com
To me you asked a good question. How do we decide the optimum release
schedule.
Surely there are many businesses that use scrum on hardware, software,
and other things, that I hesitate to make one rule that applies to
all.
I hear people say: "Well, the customers only want one release per
year." No doubt you have heard this. My reaction is: "Well, we and
the customers could learn faster what they really want if we had more
frequent deliveries. So, it is our job and theirs to learn how to do
that with less pain per delivery. Like, fewer bugs, for
example." (typically that is one of the problems).
I think dictating to the customers: "You will take a release every
week now" (say, from yearly before)...dictating to them is usually not
a good business strategy. But talking to them about how we and they
will change so that they can, and they would benefit from it, that
does seem a winner to me.
Usually. I bet some clever guys will say they work in some businesses
where this idea would not work. That it must be at least 2 years, or 1
year, or 6 mos, or 3 mos. I bet some of them are even right about
that.
So, I am betting the optimum delivery frequency is a function of many
things, and that even those things might vary from business to
business or industry to industry.
Still, virtually always "Deliver more frequently" is right. Or so it
seems in my part of the world.
Thanks,
Joe
LeanAgileTraining.com
On Mar 17, 12:35 pm, Dan Rawsthorne <dan.rawstho...@drdansplace.com>
wrote:
> Ah, but surely the optimum release schedule is not a function of
> development, but rather a function of the business...
>
> Dan Rawsthorne, PhD, CST
> Senior Trainer/Coach, CollabNet
> drawstho...@collab.net, 425-269-8628
Ron Jeffries
wrote:
> Some people can interpret what Ron said to imply, if you have a
> "hardening sprint": "Na, na, na, na, you don't really understand
> agile." This is not what he meant (well, not always).
Seems to me it would be hard to make that interpretation, since what
I actually said was:
> It's simple, really. If a hardening Sprint is necessary, then the
> preceding Sprints were not producing Done software.
>
> Any form of specialized Sprint is evidence that the team's
> definition of Done is not solid enough and that lack is acting as an
> impediment
I didn't say anything about understanding. I said that the need for
a hardening sprint means the software isn't done (which seems to me
to be prima facie the case), and that as such it's evidence of an
impediment.
Understand? :)
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
You don't need to see my identification.
These aren't the ideas you're looking for. Move along.