[teampractices] "Maintenance" vs "New work"

[Dan Garry]

Understood. Thanks for the clarification, Joel and Terry.

Dan



On 7 August 2015 at 11:40, Terence Gilbey <tgilbey at wikimedia.org> wrote:

> The only thing I have to add is .... "What Joel said".. as he made the
> case more eloquently than I do..
>
> On Fri, Aug 7, 2015 at 11:00 AM, Joel Aufrecht <jaufrecht at wikimedia.org>
> wrote:
>
>> I'm not certain I understand the need to draw a distinction between
>>> maintenance and new work. I prefer to think purely in terms of what work is
>>> the most strategic in terms of achieving our mission; for the purposes of
>>> that, whether work is "maintenance work" or "new work" is irrelevant, as
>>> all that matters is if the work is the most strategic. Is there any
>>> background on why you are being asked to make this distinction?
>>>
>>
>> The top two reasons for me:
>> 1) In order to forecast when the VisualEditor team may complete new
>> functionality milestones, I need to understand what fraction of their
>> velocity is consumed by maintenance work.
>>
>> 2) Lila and Terry would, as I understand it, like to differentiate types
>> of work during quarterly planning and goal setting in order to understand
>> more project the Foundation's capacity for new functionality.  I think this
>> is basically 1) but at a bigger scale.
>>
>> Terry may want to weigh in further on why.  My understanding is that
>> goals and plans at WMF are often made based on a notion of engineering
>> capacity that ignores maintenance load, and so are unrealistically
>> optimistic.  (Of course there are many other reasons software forecasting
>> tends to be unreasonably unrealistic.)
>>
>> I'm also coming at the issue from the other end: what patterns exist in
>> peoples' work habits and the data, and what questions might we be able to
>> answer from the data we have or can relatively cheaply get?  I'm seeing
>> several patterns worth thinking about, either because they are directly
>> valuable to measure, or because they confound and confuse other measures
>> and need to be clarified:
>>
>> *Planned vs Unplanned*
>> This may be more useful as a tactical diagnostic.  That is, you may want
>> to measure how much of your day is under your control, and if the result
>> doesn't match your role, change something; and teams might want to check
>> this to see if they are handling more interruptions than they expect.  This
>> can help with the "stitch in time saves nine" heuristic, e.g., is it
>> cost-effective to invest in permanently solving an intermittent problem or
>> is it actually infrequent enough that 8 hours of preventative care would
>> only save 2 hours of crisis in the next 5 years?  I don't see "interruption
>> rate" as a strategic thing to measure BUT it overlaps so much with
>> Maintenance that they are easily confused.  In fact, we've been measuring
>> "Interrupt" for VE when what we mostly want to measure is probably
>> Maintenance.
>> Unplanned can also be useful to measure re: new functionality, as a
>> measure of how accurate a team's initial work breakdown or estimate is
>> compared to what is finally shipped.
>>
>> *Maintenance vs New Functionality*
>> Terry's divisions (core aka "keep the lights on", maintenance, new
>> functionality) can all be thought of in terms of, how much time do we have
>> to complete this before something bad happens?  If you think of leadership
>> as the art of "disappointing people at a rate they can absorb", then having
>> this information supports the decision of who to disappoint next.  I do see
>> gray zones between the categories, so I'd love to hear more cases for
>> having two buckets versus three buckets versus something else.
>>
>> *Bug vs Feature*
>> I haven't yet seen any teams at WMF maintaining the distinction.  Some
>> possible uses of bug lists that don't contain feature work: identifying
>> root cause patterns of preventable problems; comparing # and rate of found
>> bugs to predicted numbers of unfound bugs; identifying the cost of fixing
>> bugs and comparing that to the cost of improving processes enough to reduce
>> bug rates.
>>
>> So I'm leaning toward a default recommendation of:
>> 1) Try to track the three buckets (core, maintenance, new functions), and
>> try to confirm that teams can actually differentiate between them cleanly
>> enough
>> 2) don't track bug vs feature
>> 3) don't track planned vs unplanned, but do be careful not to
>> automatically conflate unplanned with maintenance.
>>
>> This is just a starting point; I'm sure each team is different enough
>> that it will be a challenge to find any definitions that are usable and
>> meaningful across all team.
>>
>> --
>>
>> *Joel Aufrecht*
>> Team Practices Group
>> Wikimedia Foundation
>>
>>
>
>
> --
> Terence (Terry) Gilbey
> Chief Operating Officer
> Wikimedia Foundation
> 149 New Montgomery Street
> San Francisco, CA 94105
>
> (626) 222 5230
> tgilbey at wikimedia.org <kmaher at wikimedia.org>
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150807/d4cd0234/attachment-0001.html>