Xebia Scrum Techrally

22 Apr, 2008
Xebia Background Header Wave

At April the 4th, 2008, we held another one of our quarterly Tech Rallies. A Tech Rally, as the name implies, is a whole day of technical training for the whole Software Development department.
The subject of an ITR can be almost anything, as long as it’s technically focused, or related to our work. For example, previous Tech Rallies were about Ruby, Grails, CSS/Javascript/Ajax and Oracle Databases, to name a few. This time, our Tech Rally was about creating the best SCRUM tool ever. Quite a challenge, when you’ve only got 8 hours, but to give a quick conclusion: the results were very impressive. It’s quite challenging to organize an event like this, so to put a bit of focus on the fun and team aspects, the group was divided into smaller groups (of approx. 4 people in size) and could pick the technologies of their liking.


To add to the structure, the following agenda was created:
9.00-9.15: Introduction
9.15-10.30: Coding
10.30-10.45: Small Break
10.45-12.00: Coding
12.00-13.00: Break
13.00-15.00: More coding
15.00-15.15: Small break
15.15-16.00: Final coding!!
16.00-17.30: +-15 minute presentations with beer to present ‘final’ product.
17.30-17.40: Retrospective
If this might sound like a pretty tight schedule, you’re right: it was! But with only 8 hours to spend, you need a tight schedule because you’re going to need all the minutes you can get.


The following teams where made (in advance), along with their preferred technology stack:

Team nameTechnology
Holy ScrumFlex, Grails, Relational Database
NoCRUDFitnesse, rMock, DDD
Scrum AdventureMoo, a MUD builder
ScrumclipeA Scrum tool implementation based on Eclipse RCP
Wicket ScrumOriginally based on Wicket, but turned into a Groovy/Grails/OO database implementation
Team OverkillMule/XMPP/Terracotta/RMI/Excel/etc…

After a very small introduction, each group claimed some office space to serve as a team base, and we started coding. Since we’ve all worked with different Scrum tools before, we all had a good feeling about what to create, which made the programming a bit easier and the domain much easier to grasp. There were no requirements for the tool to create, to stimulate people’s creativity, and which consequently resulted in quite some interesting ideas.
After a whole day of fanatic programming, and powered by a great sandwiches-and-soup lunch (thanks!), the teams produced the following results:

Holy Scrum
The Holy Scrum team came up with a Flex based frontend, backed up by a Grails backend with JMS communication, featuring a DSL powered XMPP interface for managing user stories. Okay, we admit, not everything worked as smoothly as we hoped it would (due to of course the time constraints and some Hibernate Proxy Serialization issues), but in the end, we had a working Flex CRUD frontend, database persistence and XMPP receiving and sending of messages. Overall a quite complete application, which, with a little bit more time, could be turned into a usable product.
The NoCRUD team had quite a different approach. Where all other teams skipped our normal 80% coverage rule, the NoCRUD team produced even more test code then in a normal project. Using Fitnesse and rSpec, the team created a testsuite based on BDD (Behavior Driven Development). This produced a very readable DSL in Fitnesse, as well as readable rSpec functional test set. When being asked which tool they preferred, the answer was of course: it depends, but with a side mark that rSpec testing is much closer to the code your are testing and is therefore easier to maintain and easier to run, without having the need to create additional fixtures, though Fitnesse might be more suitable for non-programmers.

The MudCrud took a totally different approach. No fancy frontend, no high performance backends, but just a text only input and output system. With a whole (to them) new programming languages (mOO) (quote: "How do you put something in a list?!?!?!? Aarghh!!"), the team managed to create a Multi User Dungeon (MUD) which allowed navigation between different planes (projects), handling user stories, and even planning poker! The result was really impressive and really fun to look at when the team gave a demo.
While the Scrumclipse had some trouble keeping their members in the team, and ending up with only two developers, they still managed to create a working application by using Eclipse RCP. The RCP framework gives you a small head start by creating a basic UI for you to start with, and the Scrumclipse used this example code to their advantage and extended the application to handle the Scrum domain. This resulted in a multiview user interface with dockable panels, a property editor for editing tasks, and an amazing graphically designed application splash screen.
Wicket Scrum
The Wicket Scrum consisted mainly of developers with a passion for Wicket. Surprisingly enough, the entire Wicket Application consisted of a single user interface, with 1 button, which did absolutely nothing (the button was designed to do nothing btw). What went wrong here? Well, not much really, but the Wicket Scrum team focused mainly on the use of an OO database (db4o in this case) and using the SpringBuilder form Grails to fire up their Spring config. Spring modules provides a module for integrating db4o and Spring, which makes integrating db4o in your project extremely easy. Integrating the Grails SpringBuilder in a Java web project proofed to be very difficult, above that the SpringBuilder lacked the support for adding transactions in your spring config.
The TechnoCrud team went loose on Technology Driven Architecture (TDA, a new paradigm?). Everything which seemed a bit enterprisey, scalable or fun was put into it. The team was so involved into creating the application that they had no time to prepare a PowerPoint presentation, but this was easily handled by an on the spot sequential presentation of all the team members! In short, the application was built on Mule, was clustered using Terracotta, had some RMI and (again!) XMPP interfaces, and even had exporting capabilities to Excel. There were some minor flaws in the implementation, like not being able to insert, well, actually anything, but the demo was so overwhelming we all forgot about that.


All in all, the way we executed the Tech Rally worked really well, and there was a lot of fun, hacking and learning while developing with a somewhat common goal. Everybody produced quite some interesting implementations and idea’s, and
even some of the team members were surprised by the results! I’m sure future Tech Rallies will even be better than this one, but this was one to remember!
Erik Pragt
Photos were taken by Jeroen van Erp. Check his flickr site for more photos!


Get in touch with us to learn more about the subject and related solutions

Explore related posts