[teampractices] "Maintenance" vs "New work"

[Joel Aufrecht]

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