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.
Since a couple of years different ideas, concepts and methods are propagated under the buzzwords “Agility” and “Software Craftmanship”. But how good are they working in an economic everyday project life?
Within the framework of my job at codecentric I use many of these ideas, concepts and methods in my own projects and introduce them to different customers in the context of agile consulting. In doing so I often face wide differences between theoretic ideas and practical implementation. The existing business environment and the natural inertia in change processes frequently require a decisive adoption. How can you verify agile concepts and ideas in a project situation as realistic as possible? This requires a project environment with its necessities and difficulties, but all persons involved are able to think and act agile and further more the project interfaces (i.e. to the management) are in line with the agile approach, too. The time time pressure to deliver, which is typical for a project, has to be present.
One of the integral parts of scrum is the iterative development process with fixed time boxes called sprints. In many projects the duration of sprints is a regularly dicussed parameter. First I would likt to analyse the different reasons and boundaries of iterative processes in order to get a better understanding of the advantages and disadvantages of differnt sprint durations.
Iterations in a process modell mean that the same process steps are passed through repeatedly. This can be done time-based (every n weeks) as well as event-based. Both approaches can be mixed or set up in a hierachical manner. Scrum for example uses time-based iterations (Sprints) which include both event-based (every done Backlog-Item) and small time-based (days with daily stand ups) sub iterations. In most cases there also is a production releases cycle, combining several sprints.
The iterative proceeding in agile is described in the 12 principles of the agile manifesto. The following three principles describe this detailed:
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Three main ideas about iterations result from this principles:
- Regulary reflect the development process
- Release Software as soon as possible to production and incrementaly upgrade it
- Regulary present running software to the stakeholders
All three ideas can be independently managed, both in control type (time or event) and in control parameters (1 day / 4 weeks).