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 <[email protected]> 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 [email protected] <[email protected]>
_______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
