Open Space Software Development at the ALE2012 unconference in Barcelona
I met Jason Ayers (@SimplyTalking ) at the XP2012 in Malmö and he told me about his rough idea of a session where people develop real software with the presetting of Continuous Delivery. This was based on the question he asked in a lightning talk at ALE2011 in Berlin as to how many people did Continuous Integration and the surprising result of only 6 out of 200 putting their hands up. I liked this idea and we started working out the details to let it happen at ALE2012 in Barcelona.
This workshop should create a project environment as realistic as possible. So the participants would have a chance to try out agile practices and learn them. We wanted to encourage people to participate as long and intensive as they want and to contribute what ever they are able and want to.
The first decision during the preparation we made was the scope of the product that should be delivered. We wanted something which is useful for the participants of the ALE2012 and which can be used immediately. So we came up with the idea of an unconference app (useable on mobile devices too) with helpful information around the event and feedback features for the users.
The second thing we decided was to start the session with a working Continuous Deleveriy Pipeline, a minimal technical architecture and one or two preimplemented features.
After some preparation skype calls (and google hangouts) and enthusiastic technical preparation from Alexandra Klimova (@aklimova ), Bastian Spanneberg (@spanneberg ) and Lars Rückemann (@lars_rueckemann ) we started on Tuesday morning in Barcelona.
In general we use “hourly iterations” with a starting stand-up where we review the current work progress and plan the next things for the next hour. Then the current participants build the next requested feature and deliver the result as soon as it is ready for production. The purpose of “iterations” was to make it easy to allow people to join at the start of a normal conference session or open space.
At the end we had 160 deployments to the test stage, 24 of them were deployed to the production stage. We had 8 committers at the GitHub repository but about 12 more people were coding (by pairing with one of 8 committers). Many more people walked in just to have a look, report a defect, request a feature or test the product. At the end there were 1649 lines of code, implementing 9 features requested from the POs.
We received a great and encouraging feedback from the participants of the ALE2012. You find the results of the closing retrospective open space on our google site . One of my perceptions was, that we act on many different levels of the software development process. Due to the personal focus everybody got insights at different levels.
After a few days back in Germany I try to write down my learnings from these three days. I start with some key situations I came across during the session.
It starts with the first hour. The main focus was on solving some technical impediments and getting the development process running. So we had not many business features ready after this first hour, because the process was being explored by the team, even by us organizers. (What do we do in the stand-ups? How are the POs involved? How to use the task board? Etc.) Nobody had the main focus on the product itself. But this was only in the first hour, from the second hour on the focus shifted more and more towards the product.
In the afternoon of the first day, we started to worry more about our customers. How do we get more people to use (and love) our product? The key situation was a discussion with Ivanna Gancheva (@IvanaGancheva ) about the main target groups of the product and the (business) value of the product. This changed our view on the product and the requirements. For me it adds another level off experiences, too: My first practical steps in lean product development.
During supper and some beers we discussed the point of target group and business value again. A pivot idea came to our mind, to change the app from an Unconference App to a mere Open Space App, skipping all around the schedule of the normal talks. After the beers this idea sounded really good, so we implemented these changes at the hotel bar during the night (with one last deployment started at 1 am with nearly zero battery power).
On next morning shortly after 8 pm the first user entered the #OSSWDev room, telling us that we have a bug. He missed the schedule in our app, the feature we had removed the evening before. The pivot idea screwed up very fast. Thanks to our Continuous Delivery Pipeline we rolled back the changes after a few minutes and the full Unconference App with schedule was online again.
Then we came to a constant delivery flow adding features like the floor plan and the comment features. This resulted in an increase of usage from the unconference participants. At that point a technical debt we made during the preparation got in focus. The first real refactoring should be made. But with no Unit and Integration Tests the team had bad feelings to start with the refactoring.
During the day there was different coaching efforts to increase testing. These pushes disturbed the developers in their flow. They were annoyed by the coaching and so these attempts weren’t successful.
Friday morning we got a request from Olaf (@OlafLewitz ) if we could provide the app for #ACCUS. So we got our first request from an outside customer. I was very proud that we got this request, but the pressure rises. We had done a lean approach with many hardcoded things and hands on developers who fixed smaller problems directly in the code or database as needed. What would it mean to provide the app to a different event?
Friday noon we closed the #OSSWDEV with the awesome retrospective open space session.
Getting back to the question “What did I learn from the Open Space Software Development?” the following items crossed my mind:
- Faster Production Release Cycles reduce the importance of tests.
- I felt the lean idea “Fail Fast”.
- Many agile practices were done unconsciously, only a few were dropped.
- A Team of POs is valuable, even for “small” products.
- Pairing helps new people to get productive really fast.
- The discussion about what is a bug and what is a change is not helpful.
- I trust in my feelings more than in absolute metrics.
- In the “real project mode” I’m like a fighter pilot. I have to rely more on my intuition and reflexes than on my rationality and conclusions.
- I like it more to let things happen in an agile way then to talk about agile (or to listen to someone else talking about it).
- There was a tremendous amount of engagement of all contributors.
For next steps that result from the OSSWDEV we distinguish the question about the future of the session format “Open Space Software Development” from the future of the product “Thot App” we developed in Barcelona.
What happens next with the product we developed in Barcelona?
First we will grant the request from Agile Coach Camp US and will provide and support a version of the App for them. But this will only be a one-time hack of the current code base, because we don’t support configurable dates, time-slots or session locations for different events.
In medium term we see two different purposes of the App. First the App could be used by events like a real product (as #ACCUS requested). Second the App is used as starting point for development sessions during an event. So we had the idea to support two versions of the app.
A “.com” version for events who don’t want to improve the app with an own development session. This version will only support a core set of features, with a stable implementation so no development support is needed during the event. This version has to be multi-event capable. Every event can use it for free.
The “.org” version will be used by events that want to run a session to improve the App. This version will have more features than the “.com” version, but some of the features could require on site development support.
What happens next with the session format?
Many of the ALE2012 participants told us to repeat the session track in future. So we offered the session track to future events like the Agile Testing Days in Potsdam or the XP Days Germany in Hamburg. Hopefully one of the events will provide us the slot to let it happen again.
In medium term we want to provide a good description of the session format, so others will be able to run the session on their own.
In the meantime we are thinking about the questions like
- What should be changed in the general session format?
- What do we as organizers have to change in our behavior due to the fact that we don’t do it for the fist time anymore?
- How can we document the outcome of a session more useful?
- Is this format reusable for educational sessions?
After all I want to give some appreciations. Thanks to Jason for the initial idea and incredible promotion during the unconference, Alexandra, Lars and Bastian for all the preparation and this huge engagement during the workshop, Adi, Marc and Yve for their upfront advises, Flavio and Franck for help us with their product ownership, Mike, Saket and all organizers of ALE2012 for the (exceptional) slot in the program and all the infrastructure and help they provided during the event and finally Alecandro, Jerome and all other participants who were in the room for a while contributing to the product.
Dein Job bei codecentric?
Agile Developer & Consultant (w/d/m)
An allen Standorten
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.