launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #07420
Re: What does rotation to maintenance really means?
On Mon, Jun 20, 2011 at 8:11 PM, Gary Poster <gary.poster@xxxxxxxxxxxxx> wrote:
>
> On Jun 3, 2011, at 5:37 PM, Francis J. Lacoste wrote:
>
>> (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 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.
>
> The Yellow squad, like other squads I think, distinguishes in our kanban board between quick jobs and what I'll call here "goal lanes." Quick jobs are for jobs that will take one or two branches, and that can be represented by a single card. In contrast, each goal will have several tasks/branches associated with each. A goal lane will typically have a single goal card, and multiple task cards.
>
> At the end of our recent LEP work, when we switched to bug rotation, we had two bugs that were really pretty big: "goals," not quick jobs. In retrospect, I think that was a mistake.
>
> Right now, AIUI, we switch to bug rotation when we have all remaining high and critical LEP bugs in progress. I propose that we try a different variation. We should switch when we have all remaining high and critical LEP bugs in progress, and none of those bugs are "goals". If there's a bug that is estimated to take more than a couple of branches, and we really think it must be tackled, then it should be given room to breathe.
I think this is a good idea.
I could also imagine that it would be more heartening than the current
situation. It would have meant that the Yellow squad would have been
officially working on the bug subscription feature for longer, but the
stop would have been cleaner. Also, it means we don't have long
periods of having only one squad burn down the critical bugs.
jml
References