Hi!Adding [email protected] to keep others in the loop - btw would be a good discussion to rather have on the buddypress. :D
On 06/30/2011 10:59 AM, david blanchard wrote:
I've thought about it, it's a good idea and maybe there is a way to do that (either by adding a command to eve, or through a shell script that parses the logs of the chat). But a little wise voice in me tells to wait and see how it plays out, before trying to automate it. We can start by using the meeting feature from eve, which already automates most of the process - then we I get tired of copy&pasting every day, I'll certainly find the envy to add the missing brick. : )Adolfo,thank you so much for this feedback on your scrum experience ! It is really valuable, and would be for all the team, so if it's ok for you I'd like to post that on the wiki page dedicated to scrum. Let me know.I share your views on these different topics, a few comments below.Let's talk on the chat whenever you want about the way redmine would be used for scrum as described on the wiki page.Thanks again :) D On 29/06/2011 23:28, Adolfo R. Brandes wrote:1) Everybody in the team communicates constantly, conveying everything from the least bit hiccup to the greatest showstopper. I can guarantee Scrum will NOT work if not only the whole team, but the whole company, is not perfectly aware of what everybody else is doing. Achieving this is not easy, but I think that Farsides has a good chance because of its transparent nature. Daily meetings are the primary tool to make this happen: if anybody misses one, it should be their obligation to read the chat logs, and it would help greatly if the daily meetings we posted somewhere separately, as soon as they finished. As a matter of fact, I already wish this were in place: just the other day I would have benefitted to know what Loic was working on, but I only found out the next day, because that's when the chat logs are published!+1we won't have the complete team present on each daily meeting (people who are on part time might not be able to be there on each day, so I agree that the log of the meeting should be easily available, and in real time.Xav do you know if we can do that in the chat ? Like put a tag at the beginning of the meeting and one at the end and have it automatically copied/paste somewhere on buddypress ? It could be done manually but since it will be everyday if there is an easy way to automate it...
Agreed with what you said about this Adolfo, everyone should keep up to date with those. The buddypress is the right place yup - actually David, I would add as a requirement to read&answer on the buddypress on a daily basis, this should help us all to have a broader vision of what everyone is working on.
There is a good deal of tickets in the tracker already - we're really not short of things to do : ) Frequent playtests, and then the influx of players usually ensure a steady flow of tickets. Then the main thing is to transform those "new" tickets into prioritized stories. It is time consuming, but with 2-3 developers, going through all tickets once a week has ensured enough tickets in the backlog to keep everyone busy.2) Product managers are not lax in prioritizing (and re-prioritizing) user stories. This should be done constantly, not just for sprint planning sessions. To be honest, this has nothing at all to do with sprints! The objective is to have as many user stories written and prioritized as is humanly possible (regardless of the whole "agile manifesto"), even if they'll be thrown away later. This is because the worst thing that can happen is if a team finishes work early and does not know what to do next. This can even affect design decisions: for instance, if Loic knew that somewhere down the line we'd be implementing chat, he could've already designed the infrastructure around this and thus saved Farsides the time and money that a backward incompatible change costs.It's a continuous work i definitely agree. And before we start any sprint planning session, the stories must be already prioritized... and numerous. For now we don't have a lot of different possible priorities (we have 4 in redmine), so at some point there might be too many stories and too few prorities which can imply a lengthy process of choice in the planning session, but i think that for now we can start with that.
For your example about the chat Lincoln, those things are bound to happen when we try to match closely the observations and remarks of players - we didn't originally thought the game would need a chat, since it was seen as more asynchronous. It's the observations of what worked well made us realize the game was more fun on the instant, and the chat played a big role in that. Fairly obvious today, but it wasn't apparent originally - even if it's always good to try to avoid it during conception, we'll get a lot of those.
3) There is a relatively clear release goal defined in terms of user stories and sprints (not necessarily time), and there is an easy, obvious way for everybody to see the team's progress, not only towards said goal, but in each sprint. Sprints themselves very quickly become meaningless if nobody knows how far behind or ahead the team is, either in terms of story points, remaining hours, or whatever metric is decided upon. "Team" is the keyword here: another thing I can guarantee is that Scrum, again, will NOT work if every developer is doing his/her own thing, unaware of what is happening around him. Example: Loic is a really productive programmer, and more often than not finishes his stuff early. But Adolfo is a newcomer to the project, and is struggling to finish his task, which blocks Chris's work. Instead of picking a new task from the board, Loic instead decides to help Adolfo, which in turn helps the team to achieve the sprint's goals. (Note: it is usually the Scrum Master's job, not the Product Manager, to guarantee this happens.)here again, i fully agree. - Regarding the team's progress :One thing i do like about scrum is the burn down chart. It's like a game for the team, to see the time and the number of remaining tasks decreasing, and try to reach the end of the sprint or of the release with all the user stories implemented. I'd like to see this included in the following sprints, once we have a first idea of the rythm of the team.- Regarding the communication / flow of information :Xav is in charge of production, and currently has more or less both roles of product manager and scrum master in the actual organization. It might become difficult and not the best thing for him to keep the two roles in the future (I tend to think that the 2 roles should be 2 different persons even in small projects), so we'll need to think about this together. Xav what do you think ?
I would be glad to be able to focus on the product manager part, if someone else takes on the scrum master role. I actually tried to convince David to take on this role, but he fears he wouldn't have the necessary availability to do it - he will be out a lot for meeting with investors, so his presence on the chat risks to be insufficient.
Actually, it makes me wonder - is it a role that you would be interested in, Adolfo?
Yes the poker planning usually works fine, i share the same experience. We can definitely try it for the first planning meeting. It actually makes me think of one thing to tackle for the planning meeting : it's video games => not only code but art, GD, etc. In my previous exp, I used to actually do 2 planning meetings : one overall with the complete team to decide the main stories to include, with very rough time estimate. Like for instance one user story = 3 days code + 1 day GD + 1 day LD + 2 days art + 1 day sound. This would be a very rough estimate with discussion but no formalized poker planning, just to give an idea of the user stories that can be included in the sprint. Then each team (code/art/etc) would meet separately, look at the part of the user stories they're in charge of, break them into tasks and poker plan it together. Then once this is done and we have a more precise estimate, we adjust the sprint backlog by adding or removing stories. Because we're a small team still, i don't think we have to split the meetings but we could follow this pattern within a single meeting.4) Everybody has to come to terms with the fact that time estimates are just guesses. But we live in the real world, and therefore we need know when things will get done! Thus, the intelligent thing to do is to try to *minimize* the amount of guesswork that goes into estimating a given task. I only know of two ways to make this happen (relatively) reliably: put a gun to the developer's head (but then you risk losing him), or just increase the information available at the time of the estimate. How? Bring more brains to the table: don't let any single person decide how long something is going to take. This is well covered in the literature, but I'll give an example anyway: the day before yesterday, I was struggling to find a way to serve Django without Apache and still integrate well with the cardstories daemon. If you had asked me then, I would have told you: "This is going to take a week." But luckily I vented my frustrations in the chatroom, and Chris came up with a quick tip off the top of his head: "Take a look at django-http-proxy!". Suddenly, I knew this was just going to take less than a day (and so it happened, even with unforeseen problems arising). Conclusion: I think Farsides should implement sprint planning sessions with everybody present, with the primary purpose of estimating task difficulty and duration. In real life, I usually do the old "planning poker" game, with great mirth and success. I think this could be easily ported to the chat room; there might even be TCL bots that do this, already.On the topic of duration, regarding the use of redmine: i'm still wondering how to distinguish tasks from user stories. The main issue i see is that currently we use the duration for payment. If we start to add duration for a user story as a whole, this won't be used for payment and it might make things a lot more complicated for the team to understand. From what i see currently, I'd do it as described on the wiki page : no concept of user story duration, only of tasks. To avoid this confusion. What do you think ?
-- Xavier.
<<attachment: xavier.vcf>>
_______________________________________________ Farsides mailing list - [email protected] Wiki: http://farsides.com/ List: http://farsides.com/ml/ Forum: http://farsides.com/forum/ Ideas: http://farsides.com/ideas/ Chat: http://farsides.com/chat/
