[maemo-community] Monthly Sprint Proposal

[From: Andrew Flegg]

2009/4/7 Qole <qole.tablet at gmail.com>:
>
> So, my proposal will start out with the simple request that the paid
> maemo.org team members follow the guidelines on the Sprints page.

I agree its disheartening to see a sea of red - and greater discipline
by the review team (Nokia, the maemo.org staff, the council) in
accepting tasks with a clear "is it done: yes/no?" and realistic
"bite-sized" (as you call them) tasks - would definitely help.

I think we need to be careful using terms like "police" and "boss",
though. The point of an agile process like this is that people choose
their tasks based on what they're interested in: this creates buy-in
and will result in a greater commitment to achieving those tasks.

Of course, there are times when there's some drudgerous task to be
done; and the tasks can't be freely choosable ("this month I'm going
to work on my tan") - but this is where having a planning meeting, and
achieving consensus will help.

I believe that the *paid* staff are professional enough to achieve
that, without having to break the process and have something *assign*
tasks to them.

When it comes to volunteers committing tasks to a sprint, we (meaning
the regular attendees to the sprint meetings) can try and suggest that
a task gets split up if we think it's too large to encompass in a
month, or doesn't have a clear target for being met.

It is interesting to me that many of the issues you raise are the
exact same ones I've seen before (in my professional capacity) in
agile processes; and the recommendations you make certainly overlap
with what we've found to be effective:

   * Split out tasks - each task should either be "done" or "not done"
     at the end of the month.

   * Activity logs - stand-up meetings or diaries. I suspect there's
     some formatting work we can do to make the maemo.org ones more
     accessible (and linking in to ongoing roles - or specific tasks -
     may help).

   * Prioritisation - things always crop up which are part of a role
     which aren't part of a specific task (i.e. p1 bugs in the website,
     small packages needing attention, etc.). This is where MoSCoW can
     come in:

         http://en.wikipedia.org/wiki/MoSCoW_Method

     Once all the tasks have been identified, they are given priorities
     of around 60% budget on "must", 20% "should" and 20% "could".
     When they are tackled in order, the "could" tasks drop out
     first when disrupting events occur.

The latter may help with the "explain why a task wasn't completed":
the only things which should need real explanations (from _anyone_
who's *committed* themselves to a task) are "must" and, probably,
"should" tasks.

The big problem here is to limit the administrative overhead for
unpaid community members who are doing things in their spare time.
There are obvious benefits to the *paid* staff of some kind of
improved process (it gives them something to point to at contract
renegotiation time), and there *are* benefits to the community as
well. But the overhead shouldn't detract people from doing "real" work
in the community - especially when it eats up into their spare time.

The advantage of an agile methodology is it allows you to pick and
choose, and react to external factors quickly. If the process needs
tweaks, and we can get consensus on what those tweaks are, there's
nothing stopping us. So, I'd especially like to hear the thoughts of
the "maemo.org four", Henri, Quim and Tero and any lay-people who've
committed tasks to the sprint process.

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:andrew at bleb.org  |  http://www.bleb.org/
Maemo Community Council chair