[teampractices] "Maintenance" vs "New work"

Fri Aug 7 18:57:32 UTC 2015

For most software development teams, there should be some (hopefully not
too much) maintenance, and the bulk of the effort (in theory) should go
toward new functionality.

And (and this is the main point of this email), for most software
development teams, "keep the lights on" should be near zero, right? So
effectively most of the teams we work with would mostly need to track 2
buckets (maintenance and new features), and if the third bucket is
substantial, that would indicate a problem.

As for bugs vs. features: We have had requests from teams to add features
to phabricator to distinguish between the two. So while I personally don't
find that distinction helpful, there are people within engineering who do.

Kevin Smith
Agile Coach, Wikimedia Foundation

On Fri, Aug 7, 2015 at 11:40 AM, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150807/71595d41/attachment-0001.html>