Xebia Scrum Techrally
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.
To add to the structure, the following agenda was created:
10.30-10.45: Small 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.
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:
|Holy Scrum||Flex, Grails, Relational Database|
|NoCRUD||Fitnesse, rMock, DDD|
|Scrum Adventure||Moo, a MUD builder|
|Scrumclipe||A Scrum tool implementation based on Eclipse RCP|
|Wicket Scrum||Originally based on Wicket, but turned into a Groovy/Grails/OO database implementation|
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:
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.
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!
Photos were taken by Jeroen van Erp. Check his flickr site for more photos!