Last year I was fortunate enough to be the Product Owner of a team that built and deployed code every hour for three consecutive days. This post describes how we did it and what the conclusions were. We will repeat the experiment at the I T.A.K.E. Unconference, at the end of this month.
The Experiment at ALE 2012
Last year I attended the Agile Lean Europe conference, together with my colleague Adi Bolboaca. He introduced me to a track that was going to run throughout the conference: the Open Space Software Development, initiated by Marc Clemens and Jason Ayers. I discussed with the initiators and we agreed that I would be a Product Owner for the development team. Because we all believed in pairing, I had a fellow Product Owner in Franck Depierre. He helped me out a lot, especially during the initial phase.
In a nutshell, we were going to start a new project from scratch and develop it during the three days of the conference, releasing as frequently as possible. Our desired frequency was hourly. Marc came to the conference together with three colleague developers, but we were expecting more people to join us.
The developers built an initial version of the app in two days, mainly so that we had the technology stack in place by the time we started. We went with a Java stack, as a result of a poll we ran prior to the conference. The team set up a Spring+Bootstrap app, and connected it to a Jenkins server for continuous integration. For version control we chose Git.
So, in the morning of the first day of the conference, we had an “empty” Spring webapp, a Continuous Integration server and an initial team of three developers, two Product Owners and two leaders. Plus we had an idea of a product to build: an application that would help comment and rate the conference presentations. We called it Thot. And we were waiting for conference attendees to join us.
What happened
During the three days, five other developers chose to join us. One of them didn’t even know Java (he was a pythonista), but enthusiastically stayed during the three days and developed side by side with the rest of the team. Ivana Gancheva came by and asked some really useful questions that helped us steer the product. Vasco Duarte came along and challenged our development practices. We’ve even had some of the conference attendees come and request feature improvements on what we were doing.
We set up a Scrum board, where I created and managed the Product Backlog for the app. Every hour, we had a stand-up where we reviewed the progress and I reprioritized the work if necessary. By the second morning we already had something the users could benefit from. We were very excited to see Vasco be one of the first users of the app. After his presentation, he used Thot to send more links to the attendees of his session.
As a Product Owner, I got up on the conference stage two times and explained our progress to the audience, asking them to use the app and provide us with feedback. Even in such a short timespan, we pivoted two times. Initially, we focused the app on feedback for the presentations. In the second morning we thought about turning it into a support app for the open space, but eventually settled down (based on user feedback) to a half/half solution. The final version contained a list of all the presentations and open space sessions, and you could comment on them.
But most importantly, we realized our ambitious goal of deploying every hour. In fact in the ~ 20 hours we were in the team room, we managed to ship out 24 production builds. In the end, we had:
- 160 developer builds
- 24 production builds
- 11 releases
- 8 committers
- 18 users that added comments
- 1649 lines of code
- 9 features
Below, you can see a screenshot of the app after three days. 
The practices we applied
Here is how we got things done:
- Standups: every hour we would stop work and assess where we were and where we were heading
- Information radiators: all of the room walls were covered with bits and pieces of information — the backlog, the task board, architectural details or server IPs are some that come to mind
- The Product Owner role: there was a single point of entry for new features and prioritization. I was talking to the smart people that attend ALE and based on that and discussions with the team I created user stories and little wireframes that the development team then implemented.
- Self-organizing team: everybody volunteered for the tasks, decided when to pair and when not etc.
- Pairing: for more complex tasks team members asked each other for help
- Retrospectives: in the first half of the project we did them hourly. After we stabilized the way we worked, we dropped to a bi-hourly frequency.
- Continuous integration: code was developed in small chunks (a few minutes) and continuously integrated using Jenkins.
- Continuous delivery: we configured Jenkins so that it could deploy to production at the click of a button.
- Acceptance testing: before we deployed to production, me or one of the other team members would run a manual acceptance test on the app.
- Walking skeleton: we started with an end to end solution.
- Celebrate: we did that every evening (-:
Sadly, we also identified some practices that we did not pay enough attention to, even though some of us used them some of the time: unit testing, TDD and merciless refactoring are the most notable ones. We deliberately decided to go fast for the three days, but in the end the code was beginning to “smell”. We decided that whoever runs the experiment next time will not allow for quality trade-offs.
What we learned
This has been an extreme environment, with a lot of pressure and “A” players. It was very intense and challenging, but we all acknowledged it was very rewarding at the same time. Being able to start a product from scratch with a new team and creating a product in ~ 20 hours is evidence of the power of agile practices. Some of the things to improve for future iterations of the workshop were:
- Be clearer about the vision from the start. We pivoted a couple of times because we did not think enough of the target user and her needs. Also, we did not “get out of the building” enough in the initial phase.
- Involve testers more. Apart from the internal testing we did, Markus Gärtner had a session on testing at the conference and he used our application as supporting material. The ~ 20 attendees identified some problems with the app that we did not think about.
- Focus on quality, refactor and write unit tests.
- Architecture matters, so think how the technology stack will support the backlog and automated testing. We initially chose a library for storing a part of the data that later proved to slow us down and made end to end automated testing hard.
Repeating the story at I T.A.K.E.
If all of the above sounds intriguing, I have some good news. During I T.A.K.E., we will have a track called Product Development where we will work exactly like that. I will be the Product Owner, and I will prepare an initial backlog for the start of the conference. Join me for one hour or maybe the entire two days, and practice for yourself what you learn during the conference, while building a real life app. Some of the speakers accepted to also join us and code for a few hours, so you will get the chance to learn in real time things like domain driven design, unit testing or TDD.
If you don’t have a ticket yet, you can get one here.
I’m looking forward to meeting you at I T.A.K.E. .
Videos
Adi recorded a few videos during ALE 2012, so you can get a feel for how it was to be part of the team.
Standup meeting
Markus debriefs us with the bugs found during his session
Final retrospective
