Re: [Scrum] What happens if the team want to ditch the Sprint Retrospective?

[Joshua Partogi]

Stefan,

My situation is actually quite unique, the team actually wants to ditch the Retrospective. 

The Scrum Master wants to have this retrospective running, because he ensures the Scrum process is running hence he makes the team start the retrospective regardless.

But then the team encounters the Scurm Master because in a self-managing team, the team decides whether to have a retrospective or not.

Both arguments seems to be valid.

Any idea what should be done under these circumstances?

On Fri, Aug 19, 2011 at 3:04 PM, Stefan Roock <stefan...@it-agile.de> wrote:

The Sprint Review is an important place to get feedback about the product.

Get real customers and users in the Review meeting. If they find it boring, ask them what they want to have changed.

Stefan

--
Dipl.-Inform. Stefan Roock
Senior IT-Berater, Certified Scrum Trainer

it-agile GmbH
Paul-Stritter-Weg 5, D-22297 Hamburg

Geschäftsführer: Henning Wolf, Jens Coldewey
Handelregister Hamburg, HRB: 92261
Umsatzsteuer-Identifikationsnummer: DE239483021

Fon:    +49 40 88173-300
Fax:    +49 40 88173-333
Mobile: +49 172 429 76 17
E-Mail: stefan...@it-agile.de
Twitter: StefanRoock

http://www.it-agile.de

Am 19.08.2011 um 03:37 schrieb Aspen R <asp...@gmail.com>:

> I'm looking for inspiration as to the value and usefulness of the
> Sprint Review process.  Why is it important?  Why is it needed?  I'm
> going to have to try to convince the Teams of this on Monday.
>
> To provide background, we are a small organization with two Teams.
> We're having issues with our reviews.  We basically go down a list and
> say "yes, yes, no, no, no, yes, no."  Demos are ... not really a
> chance to show off.  Instead they're usually one person pulling up a
> screen and showing one or two test cases to prove that, yes, it really
> does work, even though everyone believed them before they did the
> demo.  People are getting bored with the process and finding little
> value in it.  What value it has is as a final status checkpoint before
> beginning to plan the next sprint.  Otherwise, there doesn't seem to
> be much point.
>
> It doesn't help that the non-technical "stakeholders" (management,
> sales, business operations) don't attend as they find the meeting to
> be too uninteresting, too long, and too technical.  We've had to
> institute a separate review meeting before each release that is
> basically a Review meeting without the technical teams, just the Scrum
> Masters sharing the results of the past several sprints with our
> internal stakeholders.
>
> Inspiration?  Thoughts?  Anyone?
>
> --
> 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.
>

--
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.

--
@jpartogi

[RonJeffries]

Hi Joshua,

On Aug 19, 2011, at 1:31 AM, Joshua Partogi wrote:

The Scrum Master wants to have this retrospective running, because he ensures the Scrum process is running hence he makes the team start the retrospective regardless.

But then the team encounters the Scurm Master because in a self-managing team, the team decides whether to have a retrospective or not.

Both arguments seems to be valid.

The ScrumMaster has no authority, therefore he cannot "make" the team do anything.

If the team is perfect, they should stop doing Retrospectives and instead go on the road explaining to the rest of us how to be perfect. Otherwise, they need to improve and therefore need a Retrospective.

If the Retrospectives are not resulting in early, visible, and desirable changes toward improvement, perhaps what they really need is to learn how to do a decent Retrospective?

Ron Jeffries

www.XProgramming.com

I try to Zen through it and keep my voice very mellow and low.

Inside I am screaming and have a machine gun.

Yin and Yang I figure.

  -- Tom Jeffries

[Albert Arul Prakash Rajendran]

Hi,

How about scrum master asking the team "five Whys" that team feels to ditch the sprint retrospectives. May be there is a deep issue hidden in their request. May be Five Whys will bring that out.

Also Scrum master need to explain the team on why we need to have retrospectives (not because process guides that way) and how it helps to make ourselves improved every time.

Just a thought

Albert

--

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.

--
with luv,
Albert Arul Prakash
http://www.bepenfriends.com/ a free online dating web site
There are only 3 colors, 10 digits, 26 letters, 7 notes and 118 elements; its what we do with them that's important.

[Joshua Partogi]

Ron,

That is a very good explanation. So I guess in any case, if the Development Team want to ditch any component in Scrum, they have to be able to explain why they want to ditch it? CMIIW. This also includes other meeting like Daily Standup, Sprint Review and Sprint Planning I guess.

Kind regards,

Joshua.

--

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.

--
@jpartogi

[RonJeffries]

Hello Joshua,

On Aug 19, 2011, at 6:36 AM, Joshua Partogi wrote:

That is a very good explanation. So I guess in any case, if the Development Team want to ditch any component in Scrum, they have to be able to explain why they want to ditch it? CMIIW. This also includes other meeting like Daily Standup, Sprint Review and Sprint Planning I guess.

I don't think there is any "have to" in Scrum. I do think I'd like to understand what's not working for this team.

[7thpixel]

The retrospective is arguably the most important aspect of Scrum. It is difficult of a team to improve if they do not take a moment to pause, reflect and recharge.

Without retrospectives it is easy to fall into a series sprint death marches.

-- 
David J Bland
Scrumology | Enabling Agility
http://www.scrumology.net

[Alan Dayley]

If you can only do one Scrum or Agile practice, do the Retrospective.
Drop other things if you must.

Secondly, if you don't do retrospectives, you are no longer doing
Scrum and you are no longer Agile (See the twelfth principle of the
Agile Manifesto).

Thirdly, the retrospective is not the problem here. There is
something else or many somethings under the surface that the team
would rather not talk about. You need to have a tough conversation to
dig some of these reasons out into the open.

Alan

[nathan]

Here are a couple of ideas:

1. Look back and see what were the outcomes (todo, action items,..)
and were they actually committed to and adopted from previous
retrospectives. If no real change came out of the retrospectives,
then I could see how developers would just see them as "business as
usual". REAL changes need to come from them, not just talking points,
and wishful thinking.

2. Maybe try to mixup the retrospective a bit with format and focus.
I think it is very easy for them to become very dry after a few
iterations, and as a result you can find the team just going through
the motions and not truly interacting and driving out the needed
discussions. I think the book "Agile Retrospectives: Making Good
Teams Great" has some great tools in there (http://pragprog.com/book/
dlret/agile-retrospectives).

Regards,
Nathan

On Aug 20, 12:53 am, Alan Dayley <aday...@gmail.com> wrote:
> If you can only do one Scrum or Agile practice, do the Retrospective.
> Drop other things if you must.
>
> Secondly, if you don't do retrospectives, you are no longer doing
> Scrum and you are no longer Agile (See the twelfth principle of the
> Agile Manifesto).
>
> Thirdly, the retrospective is not the problem here.  There is
> something else or many somethings under the surface that the team
> would rather not talk about.  You need to have a tough conversation to
> dig some of these reasons out into the open.
>
> Alan
>
>
>
>
>
>
>
> On Fri, Aug 19, 2011 at 5:57 AM, 7thpixel <7thpi...@gmail.com> wrote:
> > The retrospective is arguably the most important aspect of Scrum. It is
> > difficult of a team to improve if they do not take a moment to pause,
> > reflect and recharge.
> > Without retrospectives it is easy to fall into a series sprint death
> > marches.
>
> > --
> > David J Bland
> > Scrumology | Enabling Agility
> >http://www.scrumology.net
>

> > On Fri, Aug 19, 2011 at 8:18 AM, RonJeffries <ronjeffries...@gmail.com>

[Bachan Anand]

I am sure others have made similar comments, since this topic is dear to my hear , I want to add my .02 cents

What has worked most with the team that I work with are,

- Switch the format around , sometimes just have retros that are casual discussion.
- As a ScrumMaster be open to reading the pulse of the team before deciding on the format.
- It is okay to skip one retro and not make a big deal out of it, if you have been doing retro for the last 10 sprints, skipping one is not too bad.
- Empathize with the team if the team is not able to make the changes they decide to do in the retro , I find that teams are open to looking at why in those situations.

..... And lastly and most importantly .. approach retro as a chance to grow and learn over having to just change .

Bachan Anand
WORK is GOOD

Irvine - Boston - Bangalore - Denver
Tel  +1-949-232-8900

Contact Me

Work is GOOD Top 10 failure modes of a Product Owner

[George Dinwiddie]

Joshua,

On 8/19/11 1:31 AM, Joshua Partogi wrote:
> Stefan,
>
> My situation is actually quite unique, the team actually wants to ditch
> the Retrospective.

That's not so unique as you think.

Describe your retrospectives. What's done during them? Who speaks and
who doesn't? What is the outcome?

> The Scrum Master wants to have this retrospective running, because he
> ensures the Scrum process is running hence he makes the team start the
> retrospective regardless.
>
> But then the team encounters the Scurm Master because in a self-managing
> team, the team decides whether to have a retrospective or not.
>
> Both arguments seems to be valid.
>
> Any idea what should be done under these circumstances?

What you describe is a power struggle (who gets to tell who what to do).
What should be done is collaborate to accomplish common goals.

No doubt there are lots of things that need to be accomplished before
you get to that point. Perhaps uncovering common goals is one of them.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Sameh Zeid]

From the last retrospective I facilitated, I got critical feedback regarding its worth, which was:

"This session is total waste of time if none of the actions are implemented within time-frame. If we could implement the actions, then it's time well spent".

Another observation if you extend the participants of retrospective to NOT just the Scrum team members, you get results which help in removing organizational impediments which could be frustrating factor to the team.

Thanks

Sameh

--

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 scrumalliance+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

--
Sameh Zeid
Email: sameh...@gmail.com, Phone: (226)444-1794, Cell Phone: (716)748-9691
Twitter: @sameh_zeid, Skype: samehsz
profile: http://www.linkedin.com/in/samehzeid
blog: www.koo-doy.com

[Liz Weatherhead]

To all those stuck in the rut of Retrospectives,

Perhaps it is the framework of the meeting that needs to be changed up.  

Because we are in a technical field, we may become stuck in black and white thinking...this shows up when we ask closed-ended, yes or no types of questions.  Open-ended, engaging questions will foster interaction and dynamic meetings.

Let me give you some examples:

• If you could explore one unanswered question what would that be?
• What is the biggest impediment we had to overcome?  How could we be more successful next time?
• If the product could say one thing to us about its experience, what would it say?
• What worked well for you personally and what would you like to change?
• What lessons did we learn?
• What feature made the biggest difference to our customer?  Why?
• What else was possible?

Ask question in the direction you want them to go.

Honor your time box for the meeting...but most importantly, do not abandon the retrospective.  It is the eye of future success.

Liz

Liz Weatherhead

Senior Trainer and Curriculum Designer

Minneapolis, MN

liz.wea...@3back.com

952.297.2990

[Mark Levison]

Joshua - you've already received heaps of great advice. I have just one question: Why does the team want to ditch the retrospective? Understanding why will help you help the team.

Must run my flight is boarding.

Cheers
Mark Levison

Mark Levison | Agile Pain Relief Consulting | Certified Scrum Trainer
Agile Editor @ InfoQ | Blog | Twitter | Office: (613) 862-2538
Recent Entries: Story Slicing How Small is Small Enough, Why use an Agile Coach

[Joshua Partogi]

Hi Mark,

The team thinks that if they need to improve they can make the decision in the Sprint instead of exclusively in the retrospective. They'd rather do the work rather than doing retrospective.

Kind regards,

Joshua.

On Mon, Aug 22, 2011 at 8:49 AM, Mark Levison <ma...@mlevison.com> wrote:

Joshua - you've already received heaps of great advice. I have just one question: Why does the team want to ditch the retrospective? Understanding why will help you help the team.

 

--
@jpartogi

[RonJeffries]

Hello Joshua,

On Aug 22, 2011, at 9:29 AM, Joshua Partogi wrote:

The team thinks that if they need to improve they can make the decision in the Sprint instead of exclusively in the retrospective. They'd rather do the work rather than doing retrospective.

Are they in fact improving rapidly?

[Brian Swan]

Hi Joshua,

How about inspect and adapt. Try running without a formal
retrospective for a couple of Sprints and see what happens. Does the
velocity improve or decline.

I have found in the past that as the team settles into a rhythm there
may not be many big improvements still there that can be extracted
from the retrospective. A retrospective can be quite expensive if you
have a team of say 8 people for an hour or two that represents a big
investment, do the improvements that come from the retrospective
offset the cost of having it?

Brian Swan

[RonJeffries]

Hi Brian,

On Aug 23, 2011, at 5:45 AM, Brian Swan wrote:

I have found in the past that as the team settles into a rhythm there
may not be many big improvements still there that can be extracted
from the retrospective. A retrospective can be quite expensive if you
have a team of say 8 people for an hour or two that represents a big
investment, do the improvements that come from the retrospective
offset the cost of having it?

However, I have found in the past that every team I have visited has had something sorely needing improvement staring them in the face.

Until Joshua's team has a defect list near zero, for example, they still need retrospectives. Until they complete almost everything they undertake in a Sprint, and have it truly ready for shipment, they still need retrospectives. And so on ...

[George Dinwiddie]

Joshua,

What would you like to have happen, now?

Looking back through the thread, I've seen people throw out possible
solutions to try. I've see people ask for more detail on the context,
but I haven't seen much in the way of answers to these questions.

On 8/22/11 9:29 AM, Joshua Partogi wrote:
> Hi Mark,
>
> The team thinks that if they need to improve they can make the decision
> in the Sprint instead of exclusively in the retrospective. They'd rather
> do the work rather than doing retrospective.

I don't see that you've said what your role is with the team. You spoke
of the scrummaster in the third person, so I presume you're not the
team's scrummaster.

How long has this team been doing Scrum? And what is the length of the
Sprint?

Describe your retrospectives. What's done during them? Who speaks and

who doesn't? What is the outcome? Are you finding the retrospectives
valuable?

[Joshua Partogi]

On Tue, Aug 23, 2011 at 8:46 PM, RonJeffries <ronjeff...@gmail.com> wrote:

Hi Brian,

On Aug 23, 2011, at 5:45 AM, Brian Swan wrote:

I have found in the past that as the team settles into a rhythm there
may not be many big improvements still there that can be extracted
from the retrospective. A retrospective can be quite expensive if you
have a team of say 8 people for an hour or two that represents a big
investment, do the improvements that come from the retrospective
offset the cost of having it?

However, I have found in the past that every team I have visited has had something sorely needing improvement staring them in the face.

Until Joshua's team has a defect list near zero, for example, they still need retrospectives. Until they complete almost everything they undertake in a Sprint, and have it truly ready for shipment, they still need retrospectives. And so on ...

Ron that is a good point. I will bring that up. In other words, until they are perfect the team still need retrospectives. 

--
@jpartogi

[Joshua Partogi]

Sorry George, I missed this.

Right now I would advise the team as Ron has advised. I think that is quite thought provoking for them. I am actually quite embarrassed to say that I am the Scrum Master :-( They have been doing 3 Sprints so far and each Sprint is 2 weeks long. Everybody speaks in the retrospective. However in the retrospective the team's mind is caged to only think that the next improvement is only related with engineering practices as advised by XP. On the last retrospective the team has run out of idea what else can be improved hence they decided to ditch the retrospective.

--

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 scrumalliance+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

--
@jpartogi

[George Dinwiddie]

Hi, Joshua,

On 8/25/11 7:48 AM, Joshua Partogi wrote:
> Sorry George, I missed this.
>
> Right now I would advise the team as Ron has advised. I think that is
> quite thought provoking for them. I am actually quite embarrassed to say
> that I am the Scrum Master :-(

Don't be embarrassed. Everybody starts somewhere.

> They have been doing 3 Sprints so far and
> each Sprint is 2 weeks long.

Realize that you're just getting started. That's a very normal time to
start noticing things that aren't working for you. The key is to look
at what you want from them and why they're not working--not just ditch them.

> Everybody speaks in the retrospective.
> However in the retrospective the team's mind is caged to only think that
> the next improvement is only related with engineering practices as
> advised by XP. On the last retrospective the team has run out of idea
> what else can be improved hence they decided to ditch the retrospective.

Describe the format of your retrospectives. Who facilitates? How are
they conducted? What exercises are performed? What's the general tone
of the participants? How many improvements are selected? Do the
improvements get accomplished?

[LESLIE SCANTLING]

Joshua - In my humble opinion, when i look at the very large sweeping issues your team has brought up in their retros, I can understand their frustration.  They are bringing up very broad issues that it might be hard to move the needle on.  One thing i notice with my teams, is that those who do valuable, concise retrospectives, discuss some of the nuances with stories, testing, how they approached the work, etc, on a smaller scale, often addressing ways the Product Wwners feeds work in user stories, or how the QA resource was or wasn't able to finish validation and discussing why.  It might be helpful for you to read some of the actual retrospective documents that have come out of some of our sessions - they are quick one page wiki docs.  I would be happy to share some with you as examples.  It might help you direct team with questions and other areas of improvements they aren't addressing.  If you want your direct email, I would be happy to give some info.
 
Leslie
 

> Date: Thu, 25 Aug 2011 11:31:55 -0400
> From: li...@iDIAcomputing.com
> To: scruma...@googlegroups.com
> Subject: Re: [Scrum] What happens if the team want to ditch the Sprint Retrospective?

> --
> 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.

[Mark Levison]

Josh sorry I'm only replying occasionally, I've get a solid backlog of my own work (revenue generating ;-)

On Mon, Aug 22, 2011 at 9:29 AM, Joshua Partogi <joshua....@gmail.com> wrote:

Hi Mark,

The team thinks that if they need to improve they can make the decision in the Sprint instead of exclusively in the retrospective. They'd rather do the work rather than doing retrospective.

" if they need to improve" - this comment really stands out for me, that implies that they're done improving. In a case like this I might find a story of an org with a similar class of technical problem that has dialed it up 15 (better than 11 ;-) and ask how they currently measure up. In recent times I've helped one company has a fair sized web presence realize that far more is possible when we discussed some large users of Continuous Delivery, Flickr. The people I was talking to agreed that Flickr is bigger then their site in both traffic, database size and complexity. So if Flickr can do continuous delivery so can most web development shops. Sometimes people just need to see what is possible.

In addition we need to understand why're you're doing Agile and what the sense of urgency is. Helping the team understand that might help.

[Michael James]

Mark, would love to see a case study of Flickr if it's OK to disclose more.  I think these positive examples are more persuasive than all the theory in the world. 

--mj

http://ScrumReferenceCard.com

--

[Mark Levison]

On Thu, Aug 25, 2011 at 3:37 PM, Michael James <mj4s...@gmail.com> wrote:

Mark, would love to see a case study of Flickr if it's OK to disclose more.  I think these positive examples are more persuasive than all the theory in the world. 

Honestly its nothing more than googling: http://code.flickr.com/ and http://sna-projects.com/blog/2011/06/continuous-deployment-flickr/ ....

I found about them months ago when someone at client said: "Continuous Deployment is clever but it will never work for ..." <insert size/other special problem here>. So I googled large Continuous Deployment and low and behold I found Flickr.

Surprise they agreed that Flickr is bigger than they were in all meaningful ways.

[Joshua Partogi]

Hi George

On Fri, Aug 26, 2011 at 1:31 AM, George Dinwiddie
<li...@idiacomputing.com> wrote:
> Describe the format of your retrospectives.  Who facilitates?  How are they
> conducted?  What exercises are performed?  What's the general tone of the
> participants?  How many improvements are selected?  Do the improvements get
> accomplished?

The format is a discussion and brainstorming. The ScrumMaster
facilitates the retrospectives and let the team choose what aspect
they want to improve for the next Sprint. Because the team is very
technical, most of the discussion revolves around improving
engineering practices, i.e latest frameworks, continuous integration,
BDD, etc. Improvements get accomplished. But the point is the team
things that rather than allocating special time to do retrospectives,
they said why can't they just do that within the sprint? The team gets
the idea from Kaizen that is implemented in Toyota where the team
gather in an instance to find a way where they can improve rather than
going to a specially allocated sprint retrospective.

--
@jpartogi

[Joshua Partogi]

Thanks for the advise Mark. Very much appreciated. We will take it into consideration.

--

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.

--
@jpartogi

[7thpixel]

I'm glad Mark mentioned Flickr, as I feel they are on the front lines of this with regards to doing it at scale. It is cool that you are helping get that message out to those who feel like they cannot possibly do it :)

FYI the slides for Flickr CD / Dev Ops are here: http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

-- 
David J Bland
Scrumology | Enabling Agility
http://www.scrumology.net

[George Dinwiddie]

Joshua,

Thanks for giving me a better understanding of the situation. I'll make
some comments in-line, below.

On 8/26/11 6:06 AM, Joshua Partogi wrote:
> Hi George
>
> On Fri, Aug 26, 2011 at 1:31 AM, George Dinwiddie
> <li...@idiacomputing.com> wrote:
>> Describe the format of your retrospectives. Who facilitates? How are they
>> conducted? What exercises are performed? What's the general tone of the
>> participants? How many improvements are selected? Do the improvements get
>> accomplished?
>
> The format is a discussion and brainstorming.

I suspect you'll get more value from a more structured retrospective.
In particular, I find that a data-gathering phase is essential to a
healthy retrospective. Even when the team is all working together in
one room, they generally find (if they do such an exercise) that they've
not all noticed the same things, and when they have, they haven't all
remembered or interpreted them in the same way.

I've come to the conclusion that without some /shared review of the
past/ then it really isn't a retrospective.

> The ScrumMaster
> facilitates the retrospectives and let the team choose what aspect
> they want to improve for the next Sprint. Because the team is very
> technical, most of the discussion revolves around improving
> engineering practices, i.e latest frameworks, continuous integration,
> BDD, etc.

These are the easy things for them. What things are they not
considering? The amount of time spent estimating during sprint
planning? Interpersonal relationships between team members? I would be
very surprised if everything else is running perfectly smoothly.

> Improvements get accomplished. But the point is the team
> things that rather than allocating special time to do retrospectives,
> they said why can't they just do that within the sprint? The team gets
> the idea from Kaizen that is implemented in Toyota where the team
> gather in an instance to find a way where they can improve rather than
> going to a specially allocated sprint retrospective.

For making most changes in their technical practices, I quite agree.
When someone has an idea for an improvement, they should bring it up
right then, not wait for the retrospective.

A retrospective, though, is different from a general discussion on
improvements. A retrospective is a look at the past to guide our
decisions on what we want in the future.

[Dan Diep]

A kitten will die if you ditch retrospectives.

[Eric Bevill]

> The format is a discussion and brainstorming. The ScrumMaster
> facilitates the retrospectives and let the team choose what aspect
> they want to improve for the next Sprint. Because the team is very
> technical, most of the discussion revolves around improving
> engineering practices, i.e latest frameworks, continuous integration,
> BDD, etc. Improvements get accomplished.

Joshua,

You are not the only one having this difficulty nor is it unique to
Scrum. In my opinion it usually has nothing to do with the most
common excuse (waste of time) and more to do with fear and the thought
that this is all about what they did wrong who didnt get something
done. Work on changing how this ceremony is viewed and I think you'll
overcome this.

Retrospectives are a room of your peers and if this is held as a "what
did we screw up" meeting the team will often respond negatively
towards it.

Why not fix it on the fly? That way I can talk to someone one on
one. This is very common whether in Scrum or any other meeting in an
organization. I see it all the time where someone has nothing to say
in a meeting, but as soon as its over they are at the cubicle of
someone else in that meeting.

It is very important to find out "what was screwed up", but better if
asked "What did not work well?" or "What can we improve on?" Make
sure that you also discuss what did go well and how you continue to
grow on that. This absolutely cannot become a blaming session where
everything I did was great and if it wasnt for Joe.... Fear is more
and more common in organizations and you must have a trusting group
without fear of having a discussion around why what they did was or
was not the best way to do it. Again, the team needs to absolutely
understand that nobody ever does it the best way all of the time or
none of us would even belong to these groups. It should also be noted
that this isnt about an individuals skills, but how we as a team used
what we have, applied it throughtout the week/sprint and ended up
today where we thought we would two weeks ago. Only three sprints in
you should have plenty to discuss here.

Now that you know what you did well and what could use improvement
(This should be very visible somewhere at this point), discuss it.
What, When, Where, Why and drop the Who. Now, most importantly the
How. How do we sustain what went well in our Sprint so that we can
continue to capitalize on it and How do we address what did not work
well.

This should be energetic/positive and you will soon see hype around
it. Everyone likes to improve...

> But the point is the team
> things that rather than allocating special time to do retrospectives,
> they said why can't they just do that within the sprint? The team gets
> the idea from Kaizen that is implemented in Toyota where the team
> gather in an instance to find a way where they can improve rather than
> going to a specially allocated sprint retrospective.
>

Any sports fans? Look at like the NFL. Tuesday through Saturday is
open practice. The team works all week long and anyone can see
exactly what they are doing. Come Sunday it is time to show everyone
what they worked on. Yes they meet everyday after practice and they
huddle between each play to ensure they are on the same page, but
MONDAY. This is the time that the team isnt on the field. They are
together discussing all that work they did last week and how they
thought it would come out on Sunday. This is the time when they are
going to figure out how to build on what did and did not work before
they put all their efforts back into another week of work.

The bottom line is this is not unique to Scrum and if you do not want
to inspect and adapt your in the wrong line of work.