[teampractices] Retrospectives

Arthur Richards arichards at wikimedia.org
Tue Dec 10 00:36:05 UTC 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20131209/61aab244/attachment-0001.html>


More information about the teampractices mailing list