Yes, thanks for the prod qubodup What went well?
In general, I think the Trac ticket backlog was quite successful at keeping us organized and on-track. In particular, I thought that the Trac ticket dependencies (blocking, blocked by fields) and depgraphs (e.g. http://parpg-trac.cvsdude.com/parpg/depgraph/264
) were very helpful for figuring out which tasks to prioritize. AFAICT everyone on the team seemed comfortable working with the Trac tickets and the backlog, though there was some hesitation in the beginning for those who hadn't dealt with Trac much in the past.
I thought that the twice-weekly sprint meetings were extremely useful at keeping everyone in the loop. Twice a week seemed like a good frequency to me - it gave us enough time to work on smaller tasks and report our progress, and also allowed us to quickly discuss and assign new tasks as needed. The strict meeting structure was good at keeping us on-topic, and overall I thought the meetings were very productive.What didn't go well?
The momentum from the first two weeks died off rather rapidly in the second two weeks. Based my own experience and observations of the rest of the team, I think what caused this slowdown was a series of structural problems with PARPG which blocked progress in several departments. For instance, in the programming department I was not able to fully implement character statistics because the current model system makes it very difficult to add new things to characters and other game entities. In the graphics/GUI department qubodup and Q_x were unable to work with PyChan and its complexities and eventually I ended up having to work on both the PyChan GUI and game model code, neither of which were easy to deal with.
My only complaint about the meetings was that I would have liked some time to discuss solutions to problems we brought up during the meeting. In theory we were supposed to discuss solutions in-between meetings, but timezone differences and time commitments outside of PARPG made this almost impossible.
In the final week and a half of the sprint we lost barra and shortly thereafter myself due to family and school commitments, which I think contributed to the slowdown and made resolution of the sprint difficult.What would I change?
I would like more time during the sprint meetings to discuss solutions to problems encountered during the sprint. Perhaps adding 20-30 minutes to the sprint meeting times? We could break away into smaller groups during this problem-solving meeting time, and those who don't have anything to contribute would be free to leave.What is my overall impression of the sprint?
A fantastic success, though not for the reasons we originally based the sprint on. We did not fully implement any of the user epic stories and from a purely numerical standpoint only completed 68% of the tasks we set for ourselves. However, we learned A LOT
about how to communicate with each other and how how to organize and deal with a series of tasks as a team. Before the sprint we were a bunch of individuals working in parallel, but during the sprint we came together to solve problems as a team
. We now have an organizational framework that we know works, and I would say that is a major accomplishment.
We also discovered several major structural problems with PARPG which we may not have encountered working alone. It is extremely important that we deal with these structural issues early in PARPG's development, otherwise we may end up with product that not only requires an enormous amount of maintenance but that only a few key developers know how to maintain! Not a good outcome for an open-source project which relies on volunteers with a high turnover rate.Conclusion
The sprint may not have gone as we originally planned, but I think we did a great job and learned a lot in the process. Now that we know what's blocking our progress we should regroup and start brainstorming about how to tackle those issues. Hopefully we'll be able to start another sprint soon and with the lessons learned from this sprint be able to make some real progress!