This week we gathered around ten of the KDE Frameworks contributors for a sprint focusing on preparing the release. As usual I went the let's have a board with sticky notes route. We dumped information from the wiki there and been working on tasks since then. By the look of that board this morning I would say we did a nice job. At the time of writing, almost everything is gone:
- we still have 4 rather small release blockers to be addressed;
- we have three nice to have tasks to be addressed;
- we have 5 release blockers in progress;
- we covered 4 discussion topics;
- we finished 42 tasks (I kid you not!).
This time, to manage the board I used a different technique. I didn't limit the WIP. Instead, I have been regularly adding smaller orange sticky notes to the tasks in the WIP lane (roughly every three hours). That was a nice way to spot tasks which were causing pain for people as they were banging their head on them. You can see the effect on the picture below which I took earlier during the sprint:
I think that for a short lived board it is a good approach. Developer sprints like we practice are probably too short and hectic to benefit from WIP limitations or more complex metrics as we'll never reach the point of having moved enough items for statistics to be relevant. On the other hand, with this very simple technique, you can quickly see some kind of flower blooming on the difficult tasks.
From the discussions going on there, the biggest outcome has been about the release cycle. We got several times the question already, so it was time to take a decision. I purposefuly delayed that decision to make sure we could discuss it properly during the sprint.
We juggled with several options, and came up with something ambitious. We are going to proceed with a one month release cycle. With the other policies we had in place for a while now, it should help reaching the stability goals we want for the frameworks while respecting the current team dynamic. As a consequence some of the work which happened at the sprint was about perfecting some of the tooling around release management.
The expected outcome should be:
- more dog fooding from framework developers;
- more contributions from application developers;
- more automated tests and peer reviews;
- and last but not least, finer grained feature delivery.
All together it should pave the way to continuous quality improvements.
I'll leave in a couple of hours. It has been really nice to witness and be part of the progress made during the last few days. We're really near from release now. Except if we hit a major issue in the coming weeks, we should be well positioned to release KDE Frameworks 5.0 in early June as planned.
Also I'd like to thank Blue Systems for hosting us in their Barcelona office. In particular, a big thank you goes to Aleix for his patience and dealing with our not so spanish daily schedule. :-)
PS: As I was writing this blog, two of the remaining release blockers got solved. By the time I get home I wonder if there will be stuff left to do. ;-)