Two months of squads: reviews and prospects
Launchpad has been operating in the squad structure for two months now. From my point of view, things have been going very well.
We are making steady progress on fixing timeouts, OOPSes, regressions and other operational issues.
The blue squad switched to maintenance after completing the ‘daily build’ project. The orange squad should follow-up soon once they complete the ‘sharing translations upstreams translations in Ubuntu’ project.
The cross-domain pollination is paying off. Having the API expert working as part of the squad finishing off the ‘daily builds’ work resulted in a long-due overhaul of our AJAX infrastructure. See the drive-by ajaxification of the blueprint page for the results! We saw similar things happen on the orange squad where the knowledge around the job system was put to good use.
I’ve got a lot of good feedback from developers who enjoy the enhanced focus they get in this new configuration.
As expected, the pace is picking up as the new squads learn to operate better together. The average of bugs closed per week went from 63 to 84.
At the last Thunderdome (whole Launchpad team in person-meeting) where we kicked off the reorg, I issued a challenge: by the next Thunderdome (scheduled for the last week of June) we should:
- have no timeouts with a cut-off at 9s;
- have an empty critical bugs queue;
- be on our way to delivering new features within 45 days on average
The next Thunderdome is now 3 months away. How are we doing?
Yesterday, Robert announced that the timeout was lowered to 11s. That means we have 2 seconds left to go! Looks like this is going well.
On the second point, we have today 224 open critical bugs on the Launchpad project. We started at 264. So on the surface, it’s not going well. The trick here is that there were a lot of issues that weren’t on the list. So we kept finding new issues as we fixed some, giving an impression of stasis. Over the last two weeks though, we have seen a constant drop in the queue length, so I hope that all issues are now recorded and that we are on are way to burning this queue down. The fact that we are now closing 34 of those per week on average (over 21 per week when we started) gives me comfort. We need to make that number go down by 16 each week to reach our goal. So it seems well within reach!
The last one is more challenging. We have a big structural constraint that would make it hard to achieve a cycle time of 45 days on new features: our DB deployment story. Most feature will require two DB patch iterations and we deploy those every 30 days. Nonetheless, we could read this goal as getting slots free on our ‘Next’ queue. That means finishing off everything that we have in progress plus some things that we haven’t started yet. We have some big items on there. Things like derived distributions and getting our bug privacy manageable. That’s where our real challenge lie! I’m looking forward to see how this will go.
