Neat idea! Thanks for sharing.
On Wed, Oct 5, 2016 at 4:05 AM, Guillaume Lederrey
wrote:
> Thanks Kevin for the reminder!
>
> So here is a short description of the "Adjectives Game":
>
> First, note of warning, this game is probably getting deeper and more
> personal than most team are comfortab
Thanks Kevin for the reminder!
So here is a short description of the "Adjectives Game":
First, note of warning, this game is probably getting deeper and more
personal than most team are comfortable with, use with caution.
1) ask the participants to write a list of 10 adjectives that describe
the
Thank you indeed, Guillaume. I have added my interpretations of these to
the Planning Offsites page[1]. It's great to have more tools available! I
look forward to hearing about the "adjective game".
[1] https://www.mediawiki.org/wiki/Team_Practices_Group/Planning_offsites
Kevin Smith
Agile Coach
These are awesome, Guillaume. Great suggestions - thank you for sharing!
On Tue, Sep 13, 2016 at 3:16 AM Guillaume Lederrey
wrote:
> A few additional thoughts (read brain dump, not much structure here):
>
> If we want to talk more about emotions, feelings and all those fuzzy
> things (which I th
A few additional thoughts (read brain dump, not much structure here):
If we want to talk more about emotions, feelings and all those fuzzy
things (which I think we should, it isn't because it is fuzzy that it
isn't important!), we usually need to bring different kind of tools to
the table. Languag
+1 to Strine's thoughts. Very similarly and in line with David said about
getting a team to name emotions that occurred around mechanical feedback
(I'm removing the 'factual' part that David originally included because
emotions are facts too!), I've also had success combining the "mad, sad,
glad" f
The book "Agile Retrospectives" by Esther Derby and Diana Larsen has a
section on managing group dynamics and a description of the "Mad, Sad,
Glad" format. I also found an online example here [1].
I've found that if you get a team to name emotions that occurred around the
mechanical/factual feedba
Hi all,
I'm looking for advice about how to structure retrospectives to encourage
more feedback about interpersonal issues. I believe the teams I work with
feel the retros are a "safe space", but the vast majority of the issues
that come up are mechanical, not personal.
Of course, it's possible t
Thanks for all the advice everyone. I really appreciate it.
I think I'll set up our first retrospective for after the holidays, and
probably try to do them every two sprints or something.
On Mon, Dec 9, 2013 at 5:04 PM, Katie Horn wrote:
> If I may add a few personal observations to the stack.
If I may add a few personal observations to the stack...
* The first few retrospectives you have, are going to be fascinatingly
awkward. Particularly so for established teams.
I've seen this happen several times, and heard tales of many more
situations that fit the same pattern: If any of the part
On Mon, Dec 9, 2013 at 5:49 PM, Tomasz Finc wrote:
> And if we haven't given you enough info. You can find all the notes
> from the Mobile Apps team retrospectives on our team page
>
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team
>
>
Oo oo! And the mobile web team:
https://www.mediawiki.org
And if we haven't given you enough info. You can find all the notes
from the Mobile Apps team retrospectives on our team page
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team
On Mon, Dec 9, 2013 at 4:43 PM, Arthur Richards wrote:
>
>
>
> On Mon, Dec 9, 2013 at 5:24 PM, Chris McMahon
> wrote:
On Mon, Dec 9, 2013 at 5:24 PM, Chris McMahon wrote:
>
> I'll suggest you do a retrospective for every sprint. These
> retrospectives should have three aspects:
>
> What went well: celebrate your successes, you deserve it.
> What did not go well: make a list of issues encountered during the last
I started a while back a wiki (
https://www.mediawiki.org/wiki/Analytics/ScrumRetrospective) explaining the
5 why's method if you want to dig deeper into a problem. The wiki contains
some useful references and examples.
D
On Mon, Dec 9, 2013 at 7:36 PM, Arthur Richards wrote:
>
> On Mon, Dec 9,
On Mon, Dec 9, 2013 at 4:47 PM, Steven Walling wrote:
> Hey all,
>
> So one of the pieces of feedback out of our Quarterly Review last week for
> the Growth team is that we should probably start doing retrospectives to
> improve our process.
>
> I understand the theory behind retrospectives as a p
On Mon, Dec 9, 2013 at 4:24 PM, Chris McMahon wrote:
> What went well: celebrate your successes, you deserve it.
> What did not go well: make a list of issues encountered during the last
> sprint
> What to improve: this is where it gets interesting...
At the beginning of the retrospective befor
I'll suggest you do a retrospective for every sprint. These retrospectives
should have three aspects:
What went well: celebrate your successes, you deserve it.
What did not go well: make a list of issues encountered during the last
sprint
What to improve: this is where it gets interesting...
T
On Mon, Dec 9, 2013 at 3:47 PM, Steven Walling wrote:
> My first question is when should I schedule our retrospectives? For context,
> Growth is in the tail end of our fifth sprint, and sprint planning/kickoff
> meetings happen on Wednesdays for us.
Apps do them every two iterations.
Whenever we
Hey all,
So one of the pieces of feedback out of our Quarterly Review last week for
the Growth team is that we should probably start doing retrospectives to
improve our process.
I understand the theory behind retrospectives as a product owner, but since
we don't have a scrum master, I wanted to a
19 matches
Mail list logo
