launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

(Posted on the blog at http://blog.launchpad.net/general/two-monts-of-squads)

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.

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.