[teampractices] Retrospectives

[Diederik van Liere]

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 <arichards at wikimedia.org>wrote:

>
> On Mon, Dec 9, 2013 at 4:47 PM, Steven Walling <swalling at wikimedia.org>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 product owner, but
>> since we don't have a scrum master, I wanted to ask Arthur, Tomasz, Katie
>> and others about them.
>>
>> 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.
>>
>
> Whenever your team needs them.
>
> The retrospective is one potential response to agile principle #12 (
> http://agilemanifesto.org/principles.html):
> At regular intervals, the team reflects on how to become more effective,
> then tunes and adjusts its behavior accordingly.
>
> In Scrum, retrospectives traditionally happen at the end of every
> iteration, prior to kicking off the next iteration. The mobile web team
> used to adhere strictly to this, but after a while the team decided to make
> them less frequent, as the sprintly retrospectives were starting to feel
> less useful. We switched to another extreme - doing them quarterly. This
> started to feel too infrequent, and now we are doing them every two
> iterations.
>
> Personally, I find having the retrospective at the end of the cycle to
> feel really good - it's a natural break point. It allows us to focus on the
> work at hand during the course of a cycle (or two), and bring up the things
> that aren't working in a structured way that minimizes context switching
> during the middle of a cycle. At least that's the theory; we have a
> tendency to bring up issues as they happen and sometimes get bogged down in
> discussion over email, etc mid-sprint, but tend to hold off on more serious
> discussion/decision making until the retrospective. Anyway, I think ideal
> timing probably depends on what the rest of your development cycle/workflow
> is like and what the team needs. I think the important thing is that you do
> them with enough frequency to catch issues early, and have a structured
> time/space to acknowledge the things that are going really well.
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20131209/f5057dc8/attachment.html>