Open Space Software Development at ALE14 Unconference
From 20-22.08.2014 a couple of colleagues and I have been to ALE 2014 unconference. ALE is a conference focusing on Agile Lean practices and is organized via a LinkedIn user group, http://www.linkedin.com/groups/Agile-Lean-Europe-ALE-3786271
On top of a regular schedule, the conference provides Open Space sessions where attendees can suggest their own topics and get together to share their experiences.
What is Open Space Software Development #OSSWDEV?
The idea to hold an Open Space Software Development session during a conference was born in 2012. The idea is to provide a simple infrastructure setup and see what happens when developers and agile people meet and develop a piece of software with limited time and resources. For more details on how everything started check out ALE 2012 https://blog.codecentric.de/en/2012/09/osswdev-at-ale2012/
What did we prepare and bring along for ALE 2014?
- We setup a development and production infrastructure, including source code repository, continuous delivery pipeline and test/staging/production servers using Amazon EC2 instances
- We prepared a working skeleton of the application that can be used as a starting point (based on previous #OSSWDEV sessions)
- An initial backlog of user stories to get us started
- A lot of Enthusiasm
How did the team organize itself?
On the first day we got together and discussed how we wanted to approach other attendees at the conference. We setup a Kanban board and during a couple of iterations modified the different until we had a setup that fulfilled our needs. We had different colored cards for user stories, bugs, technical tasks and expedite tickets. The backblog was prioritized by our product owner, who talked to several conference attendees and gathered new user stories and bug reports. We had a couple expedite tickets that needed to be resolved until a certain timeslot so we could present a running version of the software during open space sessions. Every other hour we did short standups where we discussed the current state of the software, problems or expedite features that needed to be implemented.
How many participants did we have?
Throughout the three days we had several developers come and join us. We either helped them to get started with their notebooks or paired on one of our development notebooks. Several developers did pair programming to implement new features or to fix bugs. In total we had about 10 different source code contributors and a lot of testers that found bugs and provided new ideas for features.
How many releases did we have during the 3 days?
Every commit resulted in a new release candidate that we automatically deployed to a Test and a Staging Environment. Therefore we had 120 fully automated deployments to Test and Staging and 21 one click releases to Production (7 each day) that where triggered by the product owner. We had one production rollback to a previous software version, due to a database migration problem. The rollback was also a simple one click action.
What problems did we encounter?
We had several discussions on how to prioritize new features versus technical debts. The initial software project was started in 2012 and a couple of implementation decisions back made our work more complex. For example, dates were stored as partial Strings in the database. Everytime we needed to do time calculations or input validation, the source code became cluttered with DateFormatters and Parsers.
Even though the software was only developed in a couple of days, it had gathered some technical debt. In order to cope with that, we tried to improve the pieces of code that we touched and leave them better behind than before (Boy Scout Rule).
List of Features
Here is a list of features that were developed during the #OSSWDEV session.
- list conference sessions with speaker, time and title
- list currently active and upcoming sessions
- manage open space sessions, add new sessions
- comment on sessions
- add links to additional resources for each session / talk
- twitter wall
- search talks by speaker name
- venue map
- user feedback form
- changelog of the application
- Open Space Sessions
- Conference Schedule
- Speaker Search
- Twitter Wall
For all the geeks, here are some technicals details of the development stack used 🙂
- Java (Programming Language)
- Spring MVC
- Hibernate (ORM Mapper)
- MySQL (Database)
- Apache Tomcat (Application Server)
- Maven (Build Tool)
- Jenkins (Continuous Integration / Delivery Server)
- Sonar / Sonarqube (Sourcecode Quality Management)
- Nexus (Artifact Repository)
- Puppet (Configuration Management)
- Github / Git (Distributed Version Control)
Delivery Pipeline on Jenkins Server
Source Code Quality Management via Sonaqube
Artifact Repository with Sonatype Nexus
Previous Open Space Software Development Sessions #OSSWDEV
We had three very intense and interesting days at ALE2014 with many “heated” discussions around software development practices, clean code, technical debt, testing and agile practices. One of the most interesting lesson learned is, that it does not take long for a software to gather technical debt. Every decision to implement “simple workarounds” most likely results in problems in the longrun.
- Tip: Always leave source code better behind than you found it
- Tip: Write tests
- Tip: Never rush to a quick solution just to get the feature out of the door
- Tip: Talk to your product owner every once in a while about the user story you are implementing
- Tip: Write more tests
- Tip: Refactor code smell
- Tip: Find ways to prioritize user stories
- Tip: Validate the benefits of user stories by talking to your users
- Tip: Provide feedback mechanisms