...now that I got your attention with the catchy subject line ;-) On Sun, Feb 8, 2009 at 10:21 PM, Vassil Dichev <[email protected]> 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
