launchpad-dev team mailing list archive

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

(Published on the blog at http://blog.launchpad.net/general/what-does-
rotation-to-maintenance-really-means)

I’ve been asked this question privately a few times already. What does it mean 
for a squad to rotate from feature-mode to maintenance-mode? The question 
arises as a number of folks noticed that some members of the squad continue 
working on feature-related bugs after they are on maintenance shift. That 
happened with the former Blue squad when they completed daily builds, with the 
Orange squad when they completed sharing translations, and with the  Yellow 
squad and better bug subscriptions. So let me clarify what that boundary 
means.

In a nutshell, it means that the squad starts new work from a different queue. 
After the switch, new work will come from the general maintenance queue. 
Because we do the switch aligned with the calendar week, there is always work 
related to the feature that is still in-process (code started but not 
reviewed, or landed but not deployed, etc.) That’s the work that continues 
after the transition. After the rotation, the squad also becomes on the hook 
to cater for the user support duties related to maintenance mode.

What are the trade-off related to this boundary definition? The main impact is 
that we get a dip in maintenance related bug fixes around the rotation. That’s 
because the new maintenance squad has still some members not ready to start 
new maintenance-related work. It could be argued that because of the interrupt 
nature of the maintenance responsibilities, it would take longer to finish off 
the work related to the feature. I’m not sure that happens in practice, but I 
make note to check the data…

The alternative  would be to only rotate after all the feature-related bugs 
are done-done. The rest of the squad could fix some lower priority bugs 
related to the feature or clean-up tech-debt accumulated during their 
rotation.  It would preserve the number of people effectively working on 
maintenance around the transitions.  But it would mean that it would take 
longer before we start the next feature. And given the poor state of our 
feature cycle time, it’s not a trade-off that I (and I guess our stakeholders) 
would be willing to make at this time. We might revisit this in the future 
though.

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

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