[maemo-community] Monthly Sprint Proposal

[From: Jeremiah Foster]

On Apr 7, 2009, at 9:57, Andrew Flegg wrote:

> 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 think we need to be careful using terms like "police" and "boss",
> though.

I agree.

>
> 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:

This kind of perspective is invaluable, it strengthens the maemo  
development process.

>
>   * 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.

I think this is worth a try, it sounds workable.

Jeremiah