The less frequent the train leaves, the more important it becomes to get on it! All features "needs" to get on the train, because they are so few and far between.
And this train will be delayed. That is for sure!
It becomes a negative self-fulfilment: the releases are happening too seldom, and consequently we need to pack them with features. The result is delayed releases, and because of this there will be even longer to the next release, and therefore it becomes even more important to get all on-board before the train leaves the station.
This is the tram close to where I live. It leaves every 7th minute. It started departing with this frequency last year (down from 15 minutes), and it resulted in several changes:1) I do not look at the time before I leave my house: I am ready when I am, and there is no need to rush or worry that I wait too long
2) The driver does not wait for passengers that are too late and who is running the last 50 meters to make it. The driver just closes the doors and drive away on the scheduled time.
How do we get to this beautiful state when delivering software?
1: Create awareness, acknowledge the problem
I used to work in a team where the stability of our software decreased between releases. This was not a happy state. We saw that it could be rectified by increasing the release frequency.
Other good reasons for having more frequent releases could be: delivering value sooner, time to marked, need to respond to change, as a means to reduce work in progress and produce finished stuff
2: Build up the urge to change the situation
Change can be difficult, and it is hard to convince others. Therefore, I have usually worked with those that agre this is a good idea in the first place. Working with people that share the idea together identified the bare minimum to get started.
3: Just do it
It has sometimes felt like being a bit irresponsible to release without a big fat release process. It is important not to underestimate the power of habit and learned behaviour. Just make sure to have a new behaviour to replace it with, and that the team itself develops this, so all have the right ownership.
We also tried to release early to a few customers in the beginning, and I was suprised to see the enthusiasm and willingness to receive software before we "officially" had released it.
I have also fought (and won) against internal release-departments accusing us for being irresponsible. Fortunately, we flew under the radar for some time so that our practice of releasing often was well developed before the other departments attacked us.
4: Be aware that it is no free lunch
I learned this: there are lots of reasons we do have this long release cycles today. In order to get to short release cycles, those reasons need to be dealt with. And this is not so fun. Just hard work. You need to be patient and remember your goal and the pain you had with your long relase cycles. Someone in the team should have the role to keep the goal sparkling in front of the team, and remind them of the pain and gain relevant to your team's efforts.
Good Luck and good summer :)
I am looking forward to my tram is back on a normal 7 minute schedule, currently they run on reduced summer time tables, waiting for late running passengers, getting delayed, and making me stress getting on time in the morning.
