sprint retrospective - handling resolutions
111 views
Skip to first unread message
dotnetguy
May 25, 2012, 7:12:39 PM5/25/12
to Scrum Alliance - transforming the world of work.
In Sprint Retrospectives, the team discusses what went well and what
needs improvement. How do you normally handle the items that team
members recommend for improvement?
One could argue that small issues should be discussed and resolved in
the retrospective while more complex issues should be noted but
deferred for deeper discussion.
My first impression is that *all* attempted issue resolution should be
*deferred* so the meeting can focus solely on identifying and
clarifying issues that need to be resolved. Otherwise, some issues
could be perceived as small by a subset of the team and these issues
may not be treated with the actual amount of attention required. This
would also help keep the team focused on the task at hand.
So my perspective is that the goal of a Sprint retrospective should be
solely to *identify* issues *not* to resolve issues. The process of
addressing the issues should come later. I'm not sure if Scrum has an
official stance on this. What's your opinion?
needs improvement. How do you normally handle the items that team
members recommend for improvement?
One could argue that small issues should be discussed and resolved in
the retrospective while more complex issues should be noted but
deferred for deeper discussion.
My first impression is that *all* attempted issue resolution should be
*deferred* so the meeting can focus solely on identifying and
clarifying issues that need to be resolved. Otherwise, some issues
could be perceived as small by a subset of the team and these issues
may not be treated with the actual amount of attention required. This
would also help keep the team focused on the task at hand.
So my perspective is that the goal of a Sprint retrospective should be
solely to *identify* issues *not* to resolve issues. The process of
addressing the issues should come later. I'm not sure if Scrum has an
official stance on this. What's your opinion?
George Dinwiddie
May 25, 2012, 10:16:15 PM5/25/12
to scruma...@googlegroups.com
Hi, Dot Net,
It's not clear to me what sort of issues can be resolved during the
retrospective. Nor why the team is making recommendations rather than
choosing actions that they can accomplish.
It would help me if you would describe what retrospectives mean to you,
and give some examples of the issues the team identifies to resolve.
Much of the Scrum literature is pretty weak on the topic of
retrospectives, and I've seen a wide variety of ceremonies given that name.
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
retrospective. Nor why the team is making recommendations rather than
choosing actions that they can accomplish.
It would help me if you would describe what retrospectives mean to you,
and give some examples of the issues the team identifies to resolve.
Much of the Scrum literature is pretty weak on the topic of
retrospectives, and I've seen a wide variety of ceremonies given that name.
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
dotnetguy
May 25, 2012, 11:21:56 PM5/25/12
to Scrum Alliance - transforming the world of work.
The Sprint Retrospective is an opportunity for team members to bring
up anything about the Sprint they feel needs improvement. For
example, a team member might say he felt he had to complete work that
should have been completed by another team member. Or a team member
might say she received emails constantly which prevented her from
getting any work done....
up anything about the Sprint they feel needs improvement. For
example, a team member might say he felt he had to complete work that
should have been completed by another team member. Or a team member
might say she received emails constantly which prevented her from
getting any work done....
Kurt Häusler
May 26, 2012, 2:49:10 AM5/26/12
to scruma...@googlegroups.com
I usually see the following 5 points listed:
Gather data
Generate insight
Decide what to do
Close the retrospective
I don't know where it first came from, I can find reference to it in a lot of places:
There is a retrospectives mailing list, as well as a couple of books on the topic, as well as this cool new resource:
But often the identify problems and solve them approach works ok too.
Mix it up seems to be what many advise.
--
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.
Bachan.anand
May 26, 2012, 3:06:57 AM5/26/12
to scruma...@googlegroups.com, Scrum Alliance - transforming the world of work.
Generally the items team members identify for improvement are prioritized and actions steps take to address the root cause in the next Sprint .
Typically I find trying to go through solution for all items raised as areas of improvement not getting resolved in a retrospective as that can lead to lack of focus on trying to change too many things in a short duration .
As a ScrumMaster I suggest that team members can take up individual action items on top of the group action , some listen , some don't and some take it to heart :)
Bachan Anand
bachan...@conscires.com
http://agile.conscires.com
Typically I find trying to go through solution for all items raised as areas of improvement not getting resolved in a retrospective as that can lead to lack of focus on trying to change too many things in a short duration .
As a ScrumMaster I suggest that team members can take up individual action items on top of the group action , some listen , some don't and some take it to heart :)
Bachan Anand
bachan...@conscires.com
http://agile.conscires.com
Heitor Roriz Filho
May 26, 2012, 4:44:22 AM5/26/12
to scruma...@googlegroups.com
It comes from this book:
--
Heitor Roriz Filho, MSc, CST
Certified Scrum Trainer and Agile Coach
Massimus Consulting and Training
Heitor Roriz Filho, MSc, CST
Certified Scrum Trainer and Agile Coach
Massimus Consulting and Training
Rally Software partner
Twitter: @massimusct
Facebook: www.facebook.com/massimusct
Cel: +55 11 8256-2757
Cel: +55 11 8256-2757
Tel/Fax: +55 11 5051-8875
Abhilash c
May 26, 2012, 7:05:42 AM5/26/12
to scruma...@googlegroups.com
I recommend reading
Agile Retrospectives: Making Good Teams Great by Esther Derby & Diana Larsen
This book provides a lot of ideas about how a retrospective should be done. This is good reference book & you should make changes according to your need
From Wikipedia:
Retrospective (from Latin retrospectare, "look back") generally means to take a look back at events that already have taken place.
Retrospective is not only about looking for issues. You look back & appreciate the good things also.This open appreciation has helped a lot in my teams. The biggest problem i have seen is that we keep on deferring without any concrete actions. This is of no use. you may have 100 issues but you don't have to act on all of these at once. Put a priority on the issues like the product backlog.Take the top priority one and start solving them. At daily scrum or next retrospective the scrum master can update the progress on the issues.
Regards
Abhilash
dotnetguy
May 26, 2012, 12:03:42 PM5/26/12
to Scrum Alliance - transforming the world of work.
I don't see how an entire book can be written about retrospective
meetings.
I think the "Decide what to do" step makes sense. In some cases, the
issue may have already been addressed. In this case the SM would
still note the issue but then also note how the issue had been
resolved.
I think the other issues can be considered action items and a separate
followup meeting can be scheduled to further discuss these items. I
think most if not all of these items can be resolved after the team
has a few days to give the items some thought.
Let me know your thoughts on this....
On May 26, 6:05 am, Abhilash c <c.abhil...@gmail.com> wrote:
> I recommend reading
>
> Agile Retrospectives: Making Good Teams Great by Esther Derby & Diana
> Larsen
>
> This book provides a lot of ideas about how a retrospective should be done.
> This is good reference book & you should make changes according to your need
>
> From Wikipedia:
> Retrospective (from Latin retrospectare, "look back") generally means to
> take a look back at events that already have taken place.
> Retrospective is not only about looking for issues. You look back &
> appreciate the good things also.This open appreciation has helped a lot in
> my teams. The biggest problem i have seen is that we keep on deferring
> without any concrete actions. This is of no use. you may have 100 issues
> but you don't have to act on all of these at once. Put a priority on the
> issues like the product backlog.Take the top priority one and start solving
> them. At daily scrum or next retrospective the scrum master can update the
> progress on the issues.
>
> Regards
> Abhilash
>
meetings.
I think the "Decide what to do" step makes sense. In some cases, the
issue may have already been addressed. In this case the SM would
still note the issue but then also note how the issue had been
resolved.
I think the other issues can be considered action items and a separate
followup meeting can be scheduled to further discuss these items. I
think most if not all of these items can be resolved after the team
has a few days to give the items some thought.
Let me know your thoughts on this....
On May 26, 6:05 am, Abhilash c <c.abhil...@gmail.com> wrote:
> I recommend reading
>
> Agile Retrospectives: Making Good Teams Great by Esther Derby & Diana
> Larsen
>
> This book provides a lot of ideas about how a retrospective should be done.
> This is good reference book & you should make changes according to your need
>
> From Wikipedia:
> Retrospective (from Latin retrospectare, "look back") generally means to
> take a look back at events that already have taken place.
> Retrospective is not only about looking for issues. You look back &
> appreciate the good things also.This open appreciation has helped a lot in
> my teams. The biggest problem i have seen is that we keep on deferring
> without any concrete actions. This is of no use. you may have 100 issues
> but you don't have to act on all of these at once. Put a priority on the
> issues like the product backlog.Take the top priority one and start solving
> them. At daily scrum or next retrospective the scrum master can update the
> progress on the issues.
>
> Regards
> Abhilash
>
John Miller
May 26, 2012, 12:13:19 PM5/26/12
to scruma...@googlegroups.com
But there is an entire book written on it and it is very good.
Pick up the book, and you will see a much larger world of the power of retrospectives could be, allowing one to differentiate for their team and situation. A retro can be so much more than a + - delta. How many teams have experienced Death By The Unengaging Retrospective?
Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.
Pick up the book, and you will see a much larger world of the power of retrospectives could be, allowing one to differentiate for their team and situation. A retro can be so much more than a + - delta. How many teams have experienced Death By The Unengaging Retrospective?
Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.
Abhilash c
May 26, 2012, 12:14:33 PM5/26/12
to scruma...@googlegroups.com
Before i read the book even i had a similar doubt. :) Reading this book will give you a lot of ideas on how a retrospective meeting should be conducted
Regards
Abhilash
Abhilash c
May 26, 2012, 12:28:07 PM5/26/12
to scruma...@googlegroups.com
You don't have to solve all the problems in the retrospective meeting. Follow agile here also. Solve the highest priority ones, defer the rest but follow it up.
One of my favorite way is to add the sticky notes for impediments. just like the scrum board,Impediment also flows from "Not done > wip > done", i have a mini impediment board where i post my impediments & based on the priority of the impediments the SM is supposed to act on it. If you have a lot of impediments which requires your managers attention, go and post in his/her cabin :)
On 26 May 2012 21:33, dotnetguy <andrew.d....@gmail.com> wrote:
George Dinwiddie
May 26, 2012, 12:40:51 PM5/26/12
to scruma...@googlegroups.com
Hi, Dot Net,
On 5/26/12 12:03 PM, dotnetguy wrote:
> I don't see how an entire book can be written about retrospective
> meetings.
I can imagine you don't. You probably can't imagine an annual conference
about retrospectives, either. Many people know so little about
retrospectives they can't imagine this.
In your other message you wrote:
> The Sprint Retrospective is an opportunity for team members to bring
> up anything about the Sprint they feel needs improvement. For
> example, a team member might say he felt he had to complete work that
> should have been completed by another team member. Or a team member
> might say she received emails constantly which prevented her from
> getting any work done....
A team doesn't need to wait for the retrospective to bring up things
like this. A well functioning team will bring up such issues right away.
A retrospective is a tool for digging deeper and uncovering things that
are not already on the top of mind for the team members.
> I think the "Decide what to do" step makes sense. In some cases, the
> issue may have already been addressed. In this case the SM would
> still note the issue but then also note how the issue had been
> resolved.
>
> I think the other issues can be considered action items and a separate
> followup meeting can be scheduled to further discuss these items. I
> think most if not all of these items can be resolved after the team
> has a few days to give the items some thought.
>
> Let me know your thoughts on this....
I'd suggest, as a start, that you try to resolve issues more promptly.
And that you research a bit more about retrospectives.
- George
>> Agile Retrospectives: Making Good Teams Great by Esther Derby& Diana
On 5/26/12 12:03 PM, dotnetguy wrote:
> I don't see how an entire book can be written about retrospective
> meetings.
about retrospectives, either. Many people know so little about
retrospectives they can't imagine this.
In your other message you wrote:
> The Sprint Retrospective is an opportunity for team members to bring
> up anything about the Sprint they feel needs improvement. For
> example, a team member might say he felt he had to complete work that
> should have been completed by another team member. Or a team member
> might say she received emails constantly which prevented her from
> getting any work done....
like this. A well functioning team will bring up such issues right away.
A retrospective is a tool for digging deeper and uncovering things that
are not already on the top of mind for the team members.
> I think the "Decide what to do" step makes sense. In some cases, the
> issue may have already been addressed. In this case the SM would
> still note the issue but then also note how the issue had been
> resolved.
>
> I think the other issues can be considered action items and a separate
> followup meeting can be scheduled to further discuss these items. I
> think most if not all of these items can be resolved after the team
> has a few days to give the items some thought.
>
> Let me know your thoughts on this....
And that you research a bit more about retrospectives.
- George
>> Agile Retrospectives: Making Good Teams Great by Esther Derby& Diana
>> Larsen
>>
>> This book provides a lot of ideas about how a retrospective should be done.
>> This is good reference book& you should make changes according to your need
>>
>> This book provides a lot of ideas about how a retrospective should be done.
RonJeffries
May 26, 2012, 1:59:21 PM5/26/12
to scruma...@googlegroups.com
DNG: I think you should read one of the books on retrospectives.
R
On May 26, 2012, at 12:03 PM, dotnetguy wrote:
I don't see how an entire book can be written about retrospective
meetings.
I think the "Decide what to do" step makes sense. In some cases, the
issue may have already been addressed. In this case the SM would
still note the issue but then also note how the issue had been
resolved.
I think the other issues can be considered action items and a separate
followup meeting can be scheduled to further discuss these items. I
think most if not all of these items can be resolved after the team
has a few days to give the items some thought.
Let me know your thoughts on this....
Ron Jeffries
Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell
dotnetguy
May 26, 2012, 2:40:15 PM5/26/12
to Scrum Alliance - transforming the world of work.
Ron - ok I'll do that
Michael James
May 26, 2012, 4:50:57 PM5/26/12
to scruma...@googlegroups.com
Teams have been getting much less than they could from retrospectives because most of us come from technical backgrounds and have been slow to develop the social perceptiveness to facilitate well. There are good books such as _Agile Retrospectives_ (already mentioned), _Facilitator's Guide to Participatory Decision Making_, and _The Skilled Facilitator_. Watching a great facilitator in action is even better if you can arrange this. I haven't been to the retrospectives conference yet, but I have watched Jerry Weinberg do some great work at the Amplifying Your Effectiveness conference. Or consider bringing in someone like Ester Derby to lead a retrospective for your team.
--mj
http://ScrumTrainingSeries.com <-- includes a retrospective module currently in beta test
--mj
http://ScrumTrainingSeries.com <-- includes a retrospective module currently in beta test
dotnetguy
May 26, 2012, 7:36:04 PM5/26/12
to Scrum Alliance - transforming the world of work.
@mj - thanks for the tips :)
On May 26, 3:50 pm, Michael James <mj4sc...@gmail.com> wrote:
> Teams have been getting much less than they could from retrospectives because most of us come from technical backgrounds and have been slow to develop the social perceptiveness to facilitate well. There are good books such as _Agile Retrospectives_ (already mentioned), _Facilitator's Guide to Participatory Decision Making_, and _The Skilled Facilitator_. Watching a great facilitator in action is even better if you can arrange this. I haven't been to the retrospectives conference yet, but I have watched Jerry Weinberg do some great work at the Amplifying Your Effectiveness conference. Or consider bringing in someone like Ester Derby to lead a retrospective for your team.
>
> --mjhttp://ScrumTrainingSeries.com <-- includes a retrospective module currently in beta test
On May 26, 3:50 pm, Michael James <mj4sc...@gmail.com> wrote:
> Teams have been getting much less than they could from retrospectives because most of us come from technical backgrounds and have been slow to develop the social perceptiveness to facilitate well. There are good books such as _Agile Retrospectives_ (already mentioned), _Facilitator's Guide to Participatory Decision Making_, and _The Skilled Facilitator_. Watching a great facilitator in action is even better if you can arrange this. I haven't been to the retrospectives conference yet, but I have watched Jerry Weinberg do some great work at the Amplifying Your Effectiveness conference. Or consider bringing in someone like Ester Derby to lead a retrospective for your team.
>
Bachan Anand
May 26, 2012, 10:00:04 PM5/26/12
to scruma...@googlegroups.com
Andrew,
On Sat, May 26, 2012 at 9:33 PM, dotnetguy
<andrew.d....@gmail.com> wrote:
> I don't see how an entire book can be written about retrospective
> meetings.
Looking further into why retrospectives are important may help you
appreciate why there are books written on this topic .Traditionally we
used to hire people to fix people make them work efficient ( Managers
, Experts , Consultants etc ) . With self organizing Scrum teams this
can be disruptive and will make the teams less functional and
dysfunctional . Hence I have seen retrospective as a mechanism for
Self Organizing teams to find improvements for working better and not
based on what others think the team should change .
>
> I think the "Decide what to do" step makes sense. In some cases, the
> issue may have already been addressed. In this case the SM would
> still note the issue but then also note how the issue had been
> resolved.
>
> I think the other issues can be considered action items and a separate
> followup meeting can be scheduled to further discuss these items. I
> think most if not all of these items can be resolved after the team
> has a few days to give the items some thought.
>
> Let me know your thoughts on this....
I sense few things from what you mentioned, so wanted to reflect that with you .
1.Do you consider SM to be in charge in a retrospective ?
2.Do you think that all items that comes up in a retrospective needs
to be resolved?
On Sat, May 26, 2012 at 9:33 PM, dotnetguy
<andrew.d....@gmail.com> wrote:
> I don't see how an entire book can be written about retrospective
> meetings.
appreciate why there are books written on this topic .Traditionally we
used to hire people to fix people make them work efficient ( Managers
, Experts , Consultants etc ) . With self organizing Scrum teams this
can be disruptive and will make the teams less functional and
dysfunctional . Hence I have seen retrospective as a mechanism for
Self Organizing teams to find improvements for working better and not
based on what others think the team should change .
>
> I think the "Decide what to do" step makes sense. In some cases, the
> issue may have already been addressed. In this case the SM would
> still note the issue but then also note how the issue had been
> resolved.
>
> I think the other issues can be considered action items and a separate
> followup meeting can be scheduled to further discuss these items. I
> think most if not all of these items can be resolved after the team
> has a few days to give the items some thought.
>
> Let me know your thoughts on this....
1.Do you consider SM to be in charge in a retrospective ?
2.Do you think that all items that comes up in a retrospective needs
to be resolved?
dotnetguy
May 26, 2012, 10:31:03 PM5/26/12
to Scrum Alliance - transforming the world of work.
@bachan - I feel that the SM should guide the retrospective but let me
know if Scrum states otherwise or if you feel that's not the case.
I think that all "what needs improvement" items *should* be addressed
or at least discussed before the end of the next Sprint. I think it
would be frustrating for team members to state the same problems at
the end of each Sprint and nothing was done about it. However, since
you asked the question it sounds like you might have a different
perspective on this?
On May 26, 9:00 pm, Bachan Anand <bachan.an...@conscires.com> wrote:
> Andrew,
>
> On Sat, May 26, 2012 at 9:33 PM, dotnetguy
>
know if Scrum states otherwise or if you feel that's not the case.
I think that all "what needs improvement" items *should* be addressed
or at least discussed before the end of the next Sprint. I think it
would be frustrating for team members to state the same problems at
the end of each Sprint and nothing was done about it. However, since
you asked the question it sounds like you might have a different
perspective on this?
On May 26, 9:00 pm, Bachan Anand <bachan.an...@conscires.com> wrote:
> Andrew,
>
> On Sat, May 26, 2012 at 9:33 PM, dotnetguy
>
joseph....@gmail.com
May 26, 2012, 11:24:31 PM5/26/12
to scruma...@googlegroups.com
The purpose of the Retrospective is not just to look back. But also to take action.
As someone already mostly suggested....
1. Get creative about identifying impediments.
-- In some sense, there are impediments with everything we do, because nothing we do is perfect yet.
-- It is a very common problem that the Team is not creative enough about seeing the impediments.
2. Order the impediments
-- Which ones will increase team Velocity the most. With some cost-benefit analysis thrown in. And other things.
3. Work on the top chunky impediment.
-- If the Team can fix it, then devise a solution and/or work on a work plan to fix it.
-- If it requires approval by a Manager outside the Team, develop a business case (I like the A3 aproach to this) to show that manager.
So, #3 should be done during the Retrospective.
Normally the actual fixing of any chunky impediment is done outside the Retro, and mainly driven by the SM. The actual people who may work on the implementation of the fix to the impediment could vary -- the Team, the SM, the PO, a Manager, etc, etc. As may be appropriate.
Helpful?
Joe
LeanAgileTraining.com
As someone already mostly suggested....
1. Get creative about identifying impediments.
-- In some sense, there are impediments with everything we do, because nothing we do is perfect yet.
-- It is a very common problem that the Team is not creative enough about seeing the impediments.
2. Order the impediments
-- Which ones will increase team Velocity the most. With some cost-benefit analysis thrown in. And other things.
3. Work on the top chunky impediment.
-- If the Team can fix it, then devise a solution and/or work on a work plan to fix it.
-- If it requires approval by a Manager outside the Team, develop a business case (I like the A3 aproach to this) to show that manager.
So, #3 should be done during the Retrospective.
Normally the actual fixing of any chunky impediment is done outside the Retro, and mainly driven by the SM. The actual people who may work on the implementation of the fix to the impediment could vary -- the Team, the SM, the PO, a Manager, etc, etc. As may be appropriate.
Helpful?
Joe
LeanAgileTraining.com
dotnetguy
May 26, 2012, 11:43:02 PM5/26/12
to Scrum Alliance - transforming the world of work.
Mark Levison
May 28, 2012, 12:03:50 PM5/28/12
to scruma...@googlegroups.com
Retrospectives are in interesting Scrum. Unlike many of the other practices they come from outside Scrum originally (as George pointed out). So the Scrum literature isn't the only (or best) place to read about them.
On Sat, May 26, 2012 at 10:31 PM, dotnetguy <andrew.d....@gmail.com> wrote:
@bachan - I feel that the SM should guide the retrospective but let me
know if Scrum states otherwise or if you feel that's not the case.
Guide is a good word, the word that many use is "Facilitate". A great facilitator helps the team discover their own insights and ideas without advancing their personal agenda.
I think that all "what needs improvement" items *should* be addressed
or at least discussed before the end of the next Sprint. I think it
would be frustrating for team members to state the same problems at
the end of each Sprint and nothing was done about it. However, since
you asked the question it sounds like you might have a different
perspective on this?
Agreed if nothing changes Sprint over Sprint retrospectives quickly become hollow, boring and repetitive. However we don't normally solve the problems themselves in each retrospective. Instead the team commit to action items that will improve/solve the problem. Some simple recommendations:
- Phrase Action Items as SMART Goals (http://en.wikipedia.org/wiki/SMART_criteria)
- Set 2-3 per Sprint - more and the team is demotivated when they're not achieved. Less and there is a risk of not getting any done in the next Sprint
- Remind the team that they have SMART goals to achieve every few days.
- In the next Retrospective check which SMART goals were achieved
Also remember to focus what the team did well in the last sprint. Its very motivating to see that there is some good in the world before focusing on the problems at hand.
Cheers
Mark Levison 
Mark Levison | Agile Pain Relief
Consulting | Certified Scrum Trainings: Ottawa, Montreal
Agile Editor @
InfoQ | Blog | Twitter | Office: (613) 862-2538
ScrumMaster
Tales: Impediments are holding back the team, Stop Digging New Holes
dotnetguy
May 28, 2012, 12:26:57 PM5/28/12
to Scrum Alliance - transforming the world of work.
thanks mark - good answer
On May 28, 11:03 am, Mark Levison <m...@mlevison.com> wrote:
> Retrospectives are in interesting Scrum. Unlike many of the other practices
> they come from outside Scrum originally (as George pointed out). So the
> Scrum literature isn't the only (or best) place to read about them.
>
> On Sat, May 26, 2012 at 10:31 PM, dotnetguy
> <andrew.d.ciccare...@gmail.com>wrote:
> http://en.wikipedia.org/wiki/SMART_criteria)
> - Set 2-3 per Sprint - more and the team is demotivated when they're not
> - In the next Retrospective check which SMART goals were achieved
> Levison* | Agile Pain Relief Consulting <http://agilepainrelief.com/> |
> Certified Scrum Trainings:
> Ottawa<http://agilepainrelief.com/landing/certified-scrum-master-training-wi...>,
> Montreal<http://agilepainrelief.com/landing/certified-scrum-master-training-wi...>
> Agile Editor @ InfoQ <http://www.infoq.com/about.jsp> |
> Blog<http://www.notesfromatooluser.com/>|
> Twitter <http://twitter.com/mlevison> | Office:(613) 862-2538
> Stop Digging New
> Holes<http://agilepainrelief.com/notesfromatooluser/2012/02/scrummaster-tal...>
On May 28, 11:03 am, Mark Levison <m...@mlevison.com> wrote:
> Retrospectives are in interesting Scrum. Unlike many of the other practices
> they come from outside Scrum originally (as George pointed out). So the
> Scrum literature isn't the only (or best) place to read about them.
>
> On Sat, May 26, 2012 at 10:31 PM, dotnetguy
>
> > @bachan - I feel that the SM should guide the retrospective but let me
> > know if Scrum states otherwise or if you feel that's not the case.
>
> Guide is a good word, the word that many use is "Facilitate". A great
> facilitator helps the team discover their own insights and ideas without
> advancing their personal agenda.
>
> I think that all "what needs improvement" items *should* be addressed
>
> > or at least discussed before the end of the next Sprint. I think it
> > would be frustrating for team members to state the same problems at
> > the end of each Sprint and nothing was done about it. However, since
> > you asked the question it sounds like you might have a different
> > perspective on this?
>
> Agreed if nothing changes Sprint over Sprint retrospectives quickly become
> hollow, boring and repetitive. However we don't normally solve the problems
> themselves in each retrospective. Instead the team commit to action items
> that will improve/solve the problem. Some simple recommendations:
>
> - Phrase Action Items as SMART Goals (
> > @bachan - I feel that the SM should guide the retrospective but let me
> > know if Scrum states otherwise or if you feel that's not the case.
>
> Guide is a good word, the word that many use is "Facilitate". A great
> facilitator helps the team discover their own insights and ideas without
> advancing their personal agenda.
>
> I think that all "what needs improvement" items *should* be addressed
>
> > or at least discussed before the end of the next Sprint. I think it
> > would be frustrating for team members to state the same problems at
> > the end of each Sprint and nothing was done about it. However, since
> > you asked the question it sounds like you might have a different
> > perspective on this?
>
> Agreed if nothing changes Sprint over Sprint retrospectives quickly become
> hollow, boring and repetitive. However we don't normally solve the problems
> themselves in each retrospective. Instead the team commit to action items
> that will improve/solve the problem. Some simple recommendations:
>
> http://en.wikipedia.org/wiki/SMART_criteria)
> - Set 2-3 per Sprint - more and the team is demotivated when they're not
> achieved. Less and there is a risk of not getting any done in the next
> Sprint
> - Remind the team that they have SMART goals to achieve every few days.
> Sprint
> - In the next Retrospective check which SMART goals were achieved
>
> Also remember to focus what the team did well in the last sprint. Its very
> motivating to see that there is some good in the world before focusing on
> the problems at hand.
>
> Cheers
> Mark Levison
>
> [image: Mark] <http://www.flickr.com/photos/36331075@N00/3833840021/>*Mark
> Also remember to focus what the team did well in the last sprint. Its very
> motivating to see that there is some good in the world before focusing on
> the problems at hand.
>
> Cheers
> Mark Levison
>
> Levison* | Agile Pain Relief Consulting <http://agilepainrelief.com/> |
> Certified Scrum Trainings:
> Ottawa<http://agilepainrelief.com/landing/certified-scrum-master-training-wi...>,
> Montreal<http://agilepainrelief.com/landing/certified-scrum-master-training-wi...>
> Agile Editor @ InfoQ <http://www.infoq.com/about.jsp> |
> Blog<http://www.notesfromatooluser.com/>|
> Twitter <http://twitter.com/mlevison> | Office:(613) 862-2538
> ScrumMaster Tales: Impediments are holding back the
> team<http://agilepainrelief.com/notesfromatooluser/2011/12/scrummaster-tal...>,
> Stop Digging New
> Holes<http://agilepainrelief.com/notesfromatooluser/2012/02/scrummaster-tal...>
dotnetguy
May 29, 2012, 2:17:28 PM5/29/12
to Scrum Alliance - transforming the world of work.
Mark mentioned that retrospective action items should be stated as
SMART Goals: http://en.wikipedia.org/wiki/SMART_criteria
I think this is one good way for ScrumMasters to validate that team
concerns are addressed and resolved. However, can you recommend some
good ways for SM's to help guide team members in the way team members
state what they feel needs improvement? For example, instead of John
stating that Joe is incompetent John should say that he received more
questions than expected from Joe on the ABC interface.
Obviously, the SM can and does help guide and manage this to some
extent on the fly but I was wondering if anyone could recommend a url
advising SR rules of engagement that team members new to Scrum could
review before the SR? Something like this would help curb emotions
and provide a useful structure for constructive criticism and
feedback. Obviously there are no hard rules around the "what needs
improvement" part of the meeting because team members should not feel
constrained about expressing themselves. However, a preparatory url
would provide some general guidelines to team members new to Scrum to
help make suggestions more thoughtful and constructive and to reduce
the risk of personal attacks....
SMART Goals: http://en.wikipedia.org/wiki/SMART_criteria
I think this is one good way for ScrumMasters to validate that team
concerns are addressed and resolved. However, can you recommend some
good ways for SM's to help guide team members in the way team members
state what they feel needs improvement? For example, instead of John
stating that Joe is incompetent John should say that he received more
questions than expected from Joe on the ABC interface.
Obviously, the SM can and does help guide and manage this to some
extent on the fly but I was wondering if anyone could recommend a url
advising SR rules of engagement that team members new to Scrum could
review before the SR? Something like this would help curb emotions
and provide a useful structure for constructive criticism and
feedback. Obviously there are no hard rules around the "what needs
improvement" part of the meeting because team members should not feel
constrained about expressing themselves. However, a preparatory url
would provide some general guidelines to team members new to Scrum to
help make suggestions more thoughtful and constructive and to reduce
the risk of personal attacks....
Yves Hanoulle
May 29, 2012, 3:10:12 PM5/29/12
to scruma...@googlegroups.com
2012/5/29 dotnetguy <andrew.d....@gmail.com>
Mark mentioned that retrospective action items should be stated as
SMART Goals: http://en.wikipedia.org/wiki/SMART_criteria
I think this is one good way for ScrumMasters to validate that team
concerns are addressed and resolved. However, can you recommend some
good ways for SM's to help guide team members in the way team members
state what they feel needs improvement?
When I am doing a retrospective, I ask people to us iLanguage
that is talking about what they want.
I want to understand what you said
is the iLanguage version of
what you say is not understandable.
For example, instead of John
stating that Joe is incompetent John should say that he received more
questions than expected from Joe on the ABC interface
that second part might be a nicer way to put it, but for me it does not feel helpfull
> the result might be that Joe now does not ask a question anymore
Obviously, the SM can and does help guide and manage this to some
extent on the fly but I was wondering if anyone could recommend a url
advising SR rules of engagement that team members new to Scrum could
review before the SR? Something like this would help curb emotions
and provide a useful structure for constructive criticism and
feedback. Obviously there are no hard rules around the "what needs
improvement" part of the meeting because team members should not feel
constrained about expressing themselves. However, a preparatory url
would provide some general guidelines to team members new to Scrum to
help make suggestions more thoughtful and constructive and to reduce
the risk of personal attacks....
The retrospective prime directive is what you are after
check the agile retrospective book for more info
or "projects retrospectives" from Norm Kerth
dotnetguy
May 29, 2012, 3:23:29 PM5/29/12
to Scrum Alliance - transforming the world of work.
I went to the url someone recommended above: plans-for-
retrospectives.com. I like some of the ideas on that site. "Amazon
Review" is one of the ideas from "Set the Stage." I like this because
most people try to post thoughtful and balanced reviews on Amazon so
this approach encourages team members to make thoughtful and balanced
observations about the Sprint:
SET THE STAGE
Amazon Review (#18)
Review the sprint on Amazon. Don't forget the star rating!
Idea from: Codecentric Blog
Each team member writes a short review with:
Title
Content
Star rating (5 stars is the best)
Everyone reads out their review. Record the star ratings on a flip
chart.
Variant of 'Check In (#3)'. Can span whole review by also asking what
is recommended about the sprint and what not.
retrospectives.com. I like some of the ideas on that site. "Amazon
Review" is one of the ideas from "Set the Stage." I like this because
most people try to post thoughtful and balanced reviews on Amazon so
this approach encourages team members to make thoughtful and balanced
observations about the Sprint:
SET THE STAGE
Amazon Review (#18)
Review the sprint on Amazon. Don't forget the star rating!
Idea from: Codecentric Blog
Each team member writes a short review with:
Title
Content
Star rating (5 stars is the best)
Everyone reads out their review. Record the star ratings on a flip
chart.
Variant of 'Check In (#3)'. Can span whole review by also asking what
is recommended about the sprint and what not.
dotnetguy
May 29, 2012, 3:49:24 PM5/29/12
to Scrum Alliance - transforming the world of work.
"The retrospective prime directive is what you are after"
yves - thanks for the reference - that addresses my concern perfectly
On May 29, 2:10 pm, Yves Hanoulle <Y...@PairCoaching.net> wrote:
> 2012/5/29 dotnetguy <andrew.d.ciccare...@gmail.com>
>
> or "projects retrospectives" from Norm Kerthhttp://www.amazon.com/Project-Retrospectives-Handbook-Team-Reviews/dp...
dotnetguy
May 30, 2012, 8:39:21 PM5/30/12
to Scrum Alliance - transforming the world of work.
We passed out the sprint retrospective prime directive as handouts on
company letterhead at the sprint retrospective this afternoon and it
really helped put the retrospective on the right track.
Thanks for the rec Yves :)
company letterhead at the sprint retrospective this afternoon and it
really helped put the retrospective on the right track.
Thanks for the rec Yves :)
Reply all
Reply to author
Forward
0 new messages