[teampractices] Retrospectives

Tomasz Finc tfinc at wikimedia.org
Tue Dec 10 00:49:49 UTC 2013


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 <arichards at wikimedia.org> wrote:
>
>
>
> On Mon, Dec 9, 2013 at 5:24 PM, Chris McMahon <cmcmahon at wikimedia.org>
> 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
>> sprint
>> What to improve:  this is where it gets interesting...
>
>
> Mobile web has followed this format since we organized as an agile team, and
> personally I find it to be really useful. It's super lightweight and just
> enough structure.
>
> I've been curious about trying out other approaches, as in some ways the
> formula has started to feel a little dry and, well, formulaic, but we
> haven't tried anything else out.
>
>>
>>
>> Take the list of things that did not go well and prepare to vote on them.
>> Everyone on the team gets some number of votes, 3 or 5 or whatever.
>> Everyone on the team can distribute their votes for improvement among the
>> list of issues to be improved.  After voting, the top few issues (3 might be
>> a good number) get assigned to some person, by volunteering, by the Scrum
>> Master, by some mechanism. That person may not be the one to fix the issue,
>> but that person is the one that shepherds the fixing and moves the fixing of
>> the issue along.
>
>
> This is a really important point and I think this can make a real difference
> between a valuable retrospective and a total snoozefest. On the mobile web
> team, we chat super briefly about the things that didn't work - just enough
> so that everyone has some idea of the pain point. Then we speak more
> in-depth about the things the majority of folks feel are important. If we
> didn't do it this way and instead just spoke through all the negative
> things, we likely wouldn't get through all of it, and we'd likely spend a
> bunch of time on things that aren't as important for the team to address as
> a whole.
>
> There's a great book out on the subject of retrospectives, and it's worth a
> read:
> http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649
>
>
> --
> Arthur Richards
> Software Engineer, Mobile
> [[User:Awjrichards]]
> IRC: awjr
> +1-415-839-6885 x6687
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>



More information about the teampractices mailing list