esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject Sprints don't work (was: Sprint 1 Results)
Date Mon, 09 Feb 2009 07:41:35 GMT
...now that I got your attention with the catchy subject line ;-)

On Sun, Feb 8, 2009 at 10:21 PM, Vassil Dichev <vdichev@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

Mime
View raw message