Sprints don't work (was: Sprint 1 Results)

[Bertrand Delacretaz <bd...@apache.org>]

...now that I got your attention with the catchy subject line ;-)

On Sun, Feb 8, 2009 at 10:21 PM, Vassil Dichev <vd...@gmail.com> wrote:
> ...There's
> still a lot for me to learn from Lift and even Scala in order to reach
> optimum productivity...

Or even Apache ;-)

I think sprints don't work when people cannot commit to set amounts of
time or energy towards the sprint's goals. And with the life realities
expressed by several folks on this list, it seems like the ESME time
is like most other Apache teams, in that people's available time comes
in small unpredictable chunks.

The tried and tested way to solve this @apache (at least in the
projects that I've been involved in) is, roughly:

1. Enter all issues in JIRA

2. Define relationships between issues, so as to build a tree of issue
dependencies that shows you what's needed to achieve the goals - goals
being issues at the top of the tree. Few Apache projects actually use
this technique explicitely, but they should ;-)

3. Let people pick and choose the issues that they want to work on.
Ideally everybody can work on any issues as opposed to "all
server-side memory issues are handled by Bob" which doesn't work if
Bob cannot help at the moment.

4. Release when an agreed upon set S of issues are implemented and
verified. The release trigger is quality, not the clock. And release
early and often - releases with known issues are fine as long as
that's documented (which happens automatically if JIRA is used
consistently).

The risk is that intervals between releases might be too long, which
can be adjusted by taking issues out of S.

Just my 2 cents - I'm not saying you guys are doing it all wrong, just
suggesting an alternate way of organizing the work, that puts much
less constraints on people's time, and requires much less synchronous
communication. The key being the "anyone can work on anything" bit. In
practice, not everybody can work on everything, but people with
similar skill sets should be encouraged to work on any issue that they
are able to tackle, which also lowers the project's bus factor.

-Bertrand

Re: Sprints don't work (was: Sprint 1 Results)

[Bertrand Delacretaz <bd...@apache.org>]

Hi Robert,

On Mon, Feb 9, 2009 at 9:49 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> ...in the the spirit of http://c2.com/cgi/wiki?WhyWikiWorks and
> http://c2.com/cgi/wiki?WhyWikiWorksNot, i'd like to jump in and add a
> counter-point not because i disagree with Bertrand but i am interested
> in seeing whether sprints could work within a collaborative open
> development environment...

Thanks for this - I do agree with your point of view, and also that
the (sacred?) Apache way of doing things should not stay cast in stone
forever.

Any other opinions on this?

-Bertrand

Re: Sprints don't work (was: Sprint 1 Results)

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Feb 9, 2009 at 7:41 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> ...now that I got your attention with the catchy subject line ;-)

in the the spirit of http://c2.com/cgi/wiki?WhyWikiWorks and
http://c2.com/cgi/wiki?WhyWikiWorksNot, i'd like to jump in and add a
counter-point not because i disagree with Bertrand but i am interested
in seeing whether sprints could work within a collaborative open
development environment. i've been watching the sprints on this list
and wondering whether some of the ideas could be applied - in some
form - to help organise some other projects i'm involved in at apache.

(i also think that there's a danger that apache may become too
conservative in terms of model. our development model is well known,
has proved itself and is now widely applied. but that doesn't mean
it's perfect. sprints clearly work well for the existing esme team and
are done very openly. perhaps with some thought and some changes, it
might be possible to use them successful.)

AIUI  (hopefully, the experts will jump in and correct any
misunderstands) sprints arose from compressed, cyclic approaches to
development - fixing deadlines rather than function shipped. at the
end of the sprint, the software should be ready for customer
evaluation. this is similar to conventional open development -
software is shipped when the consensus says it's ready, rather than to
a dealine. the main difference is the short release cycles (a week or
two).

open development subscribes to the  'release early, release often'
philosophy but - in practice - the apache projects usually see long
gaps between releases. i've observed many issues - both social and
technical - in projects arise from these long gaps.

this line of reasoning leads me to propose my first "Open Source Sprints Work"

1. (Open Source Sprints Work) To release early milestones often

in other words, committing to cutting and voting on a milestone
release ever cycle

> On Sun, Feb 8, 2009 at 10:21 PM, Vassil Dichev <vd...@gmail.com> wrote:
>> ...There's
>> still a lot for me to learn from Lift and even Scala in order to reach
>> optimum productivity...
>
> Or even Apache ;-)
>
> I think sprints don't work when people cannot commit to set amounts of
> time or energy towards the sprint's goals. And with the life realities
> expressed by several folks on this list, it seems like the ESME time
> is like most other Apache teams, in that people's available time comes
> in small unpredictable chunks.

+1

it can often be difficult for occasional or new developers to pick up
small chunks of tasks to fit their small, unpredicatable chucks of
time

2. (Open Source Sprints Work) To advertise small tasks that can easily
be picked up by the community

> The tried and tested way to solve this @apache (at least in the
> projects that I've been involved in) is, roughly:
>
> 1. Enter all issues in JIRA
>
> 2. Define relationships between issues, so as to build a tree of issue
> dependencies that shows you what's needed to achieve the goals - goals
> being issues at the top of the tree. Few Apache projects actually use
> this technique explicitely, but they should ;-)
>
> 3. Let people pick and choose the issues that they want to work on.
> Ideally everybody can work on any issues as opposed to "all
> server-side memory issues are handled by Bob" which doesn't work if
> Bob cannot help at the moment.
>
> 4. Release when an agreed upon set S of issues are implemented and
> verified. The release trigger is quality, not the clock. And release
> early and often - releases with known issues are fine as long as
> that's documented (which happens automatically if JIRA is used
> consistently).
>
> The risk is that intervals between releases might be too long, which
> can be adjusted by taking issues out of S.

+1

developer's time is unpredicatable and issuing tracking is essential.
task tracking is essential to understand the progress made on a
particular issue. i've observed major problems arise (in a small
minority of projects) from this pushing method.

an alternative method would be to use a pull back. a pool of tasks is
assigned to the next full release. when a developer grabs a bit of
work, they assign it to themselves and - if they think they can
complete it in time - move it to the milestone. any work that is
unfinished when the milestone is cut is moved back into the pool.

3. (Open Source Sprints Work) uses issue management to organise and
record each milestone by selecting issues from the next release pool

- robert