Understood. Thanks for the clarification, Joel and Terry. Dan
On 7 August 2015 at 11:40, Terence Gilbey <[email protected]> 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 <[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 > > -- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation
_______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
