GSoC and Scrum

This year I helped the Gentoo GSoC project as a mentor for the first time! I mentored Jauhien Piatlicki, that worked on the g-sorcery project, that is a framework for automated ebuild generators. It is meant to replace g-octave and some of the other Gentoo automated ebuild generators in the future.

For those who don't know, Google Summer of Code is a Google program that pays a student to work during 3 months on an open source project.

I have been using Scrum at work for some time already, and asked Jauhien about trying to use it in our project. We agreed on using it wherever it made sense for our workflow. In other words, we adapted Scrum to our workflow, instead of adapt our workflow to Scrum. That's because none of us was a Scrum expert, and because we needed to follow Gentoo/Google guidelines and timeline during all the project, making it hard to apply some aspects of the Scrum methodologies.

We had sprints of 2 weeks, starting on monday, after a quick planning on IRC. We had a private IRC channel at Freenode, where we discussed stuff, had meetings, etc.

We didn't had daily meetings. We were on very different timezones, and it was quite hard to meet daily. We just used the other tools and our IRC channel to fill the gap left by the daily meetings.

We created a kanban board, using Trello:

https://trello.com/b/8WdY2ZIs/framework-for-automated-ebuild-generators

This board and the IRC channel were our main management tools, and both worked pretty well. The board cards were used for stories and the card checklists were used for the tasks.

During the first planning meeting we estimated all the backlog, to know how many points were required per sprint to keep the project on schedule, because we had a hard timeline to accomplish. These estimatives were quite useful, because everybody following the project was able to know if the work was evolving properly or not. But estimating the backlog, to accomplish a timeline, isn't an easy task, it requires good knowledge of the stories and about how everything will be implemented.

During the other planning meetings we just calculated how many points were done in the previous sprint and choose stories for the next sprint, replacing the stories already finished. I let Jauhien choose the stories he wanted to include in the sprints.

Our methodology was proven efficient right before the GSoC mid-term evaluation. All the stories planned to be finished before the evaluation were done, showing that the work was evolving like planned and that our estimatives were good enough. We were already confident on this, because all the sprints before the evaluation were finished in time. :)

Same thing before the final evaluation. All the required stories were finished!

We both had several problems during the project, but the tools made it easy to track the current state of the project easily by looking at the kanban board, at the source repository or just asking on IRC. Knowing the status of the project allowed us to focus the efforts on getting the tasks done, while still handling our personal problems in parallel.

This post isn't intended to be a Scrum tutorial or something like that. I just wanted to share the experience of using these methodologies during a GSoC project. We just adapted Scrum to our workflow, as said before. Don't be too picky! :)

If you are interested on the g-sorcery project, you can find more information here:

https://github.com/jauhien/g-sorcery

blog comments powered by Disqus