[teampractices] "Maintenance" vs "New work"

Fri Aug 7 18:40:19 UTC 2015

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150807/3b741a85/attachment.html>