Talk:Team Practices Group/Flow

Are there any no-brainer practices that all of TPG agrees are beneficial to adopt in 90%+ of relevant situations, and that almost always have a positive return? If so, what are they? To qualify, a practice must be S.M.A.R.T. : Specific, Measurable, Assignable, Realistic, and time-related.

Candidates and areas to consider:

• Don't be a jerk
  • Aware that this is a phrase that calls that specific meta page, I think this might be better summed up as "Let others be heard." As it is, I think "Don't be a jerk" works if you already know what it means, but if you're coming from the vacuum of not knowing best practices then it's only going to elicit a "well, duh," or worse yet, some folks will simply think they are not being a "jerk."
  • The linked page (https://meta.wikimedia.org/wiki/Don%27t_be_a_jerk) specifically addresses the purpose of this mantra as facilitating a space in which people can voice their opinion without being smothered or bullied or peer-pressured[1], as well as one where valid opinions remain valid despite being voiced by a "jerk."
  • TL;DR: Encouraging openmindedness around communication and opinions is, arguably, more effective at preventing "death-by-1000-papercuts" than laying down the law alone. From TPG perspective, this also means facilitating a space in which an outed "jerk" can reflect.
• Appropriate numbers and lengths of meetings
  • (vague, but true)
  • I'm not sure what this means. I recall this page (https://www.mediawiki.org/wiki/Meeting_best_practices_%28including_remote_staff%29)
  • Any meeting over 90 minutes or maybe 2 hours is probably counter-productive. Or at least needs some breaks and structure.
  • All meetings should have agendas and/or definitions of what in necessary for a meeting to be done and successful.
• Minimize waste. Too broad, but drilling in to specific kinds of waste. (NOTE: I think this is an excellent mantra that is hamstrung by the fact that one might not know if they are wasteful until after the fact. Part of iterative improvement, to be sure, but the point remains that it can be challenging the determine if an action that is yet to be taken will be wasteful.)
  • Work that is repeated
    • Prevent two different teams from solving the same problem at the same time without coordination
  • work that is never used
    • Identify when Foundation goals change and terminate orphaned work
    • Finish or abandon what you start
      • (unless there is a reason not to)
        • Is there an example of "unless there is a reason not to"? Seems to me that many unfinished tasks that are later taken up again could probably be refactored or broken up and readdressed before any yuckiness of simply picking up where one left off. It was left unfinished for a reason, so it behooves us to use that knowledge when we return to it.
  • waste from excessive context switching
• Have one, prioritized list of work to be done per work-doing unit (person or team).

For comparison, practices that are probably not simple enough to be no-brainers:

• Aim for an MVP without gold plating
  • (but definitions are debatable)
  • Isn't "avoiding gold-plating" redundant with "MVP"?
• Communicate enough but not too much
  • I like this, but I'm still chewing on it.

Here is a more technically oriented list that I think matches the above definition of no-brainer: http://spot.livejournal.com/308370.html. For example:

* Your code tries to install into /opt or /usr/local [ +10 points of FAIL ]

* Your code has no "make install" [ +20 points of FAIL ]

* Your code doesn't work outside of the source directory [ +30 points of FAIL ]

These questions are in the context of the kinds of processes we are currently using or aspiring to within WMF, such as quarterly and annual goal-setting, and per-team processes that are typically Scrum-Ban-ish or less structured.

1. What term refers to all of this stuff? More specifically, what term shall we use to refer collectively to any text that defines a scope of work and is a desired outcome, not an output or input of unit of work?
   1. High-level Planning
   2. Outcome Specifications
2. Is a set of one Objective and one or more related Key Results collectively one Goal?
3. What's the relationship between Milestones, Milestone Criteria, Objectives, and Key Results?
   1. Milestones = Objectives, Milestone Criteria = Key Results
   2. Key Results = outcomes you are trying to achieve, Milestone = collection of work that should result in some or all of a Key Result, Milestone Criteria = outputs you are trying to achieve
4. How should all of this be represented in Phabricator?
   1. Not at all - keep it in Wiki pages only.
   2. Fully, all high-level stuff should live as Phabricator objects, and things that are currently wiki pages should be replaced by Phab queries or should be maintained as synced to the results of Phab queries
5. When and how does this stuff interact with Task-level work (such as Scrum Planning, backlog grooming, and other Scrum activities and ceremonies)?
   1. In Planning Meetings
   2. In Grooming (in creating new Stories and in prioritizing)

• 1: A-ish "Planning" is simpler.
• 2: I would simplify and consolidate the concept of "Goal" for any big task that requires a significant amount of focus and work, getting rid of milestones, objectives, key results, etc.
• 3: See above. Having Goals and then subtasks to achieve those goals is enough. The added complexity doesn't bring any value, and confuses most full-time developers and basically all volunteers. IMHO.
• 4. Every object worth of planning attention should have their own Phabricator task reflecting dependencies, priorities, etc.
• 5. Meetings support Grooming, not the other way around. Grooming is an ongoing, asynchronous, remote-friendly activity open to everybody's input. Meetings are synchronous and, in practice, leaning towards restrictiveness and co-location (the problem of distance is being solved, but no tech will get rid of timezone differences). Meetings are useful to push grooming and resolve whatever the online grooming was not able to resolve.

Summary: Projects, Goals, Tasks, and Sprints are clear ingredients that allow 1000s of connections and combinations. I would be very careful introducing any other type of object to this mix, assuring that its definition and use are almost self-explanatory.

I remain intrigued by the statement that "Grooming is an ongoing, asynchronous, remote-friendly activity open to everybody's input."

I asked about this elsewhere, and only received one answer, from a PO who has seen roughly 10% of the grooming be performed asynchronously by tech leads or developers.

My guess is that in projects without a strong Product Owner, grooming is in fact a collective activity, which can be asynchronous. With a strong PO, it seems like they have to own grooming, and therefore have to be fully involved with any grooming activities. If grooming happens without them, there would need to be extensive communications to sync up. (Note that phab does not generate notifications for moving items up or down within a column.)

But as I said, I would love to hear more about this.

1. It sounds like WMF is trying the OKR method. It has a lose definition. I've never been able to find a single, well defined description of process. I've worked with it at 4 different companies. Does WMF have its own definition? If not, can we facilitate?
2. This relates to #1. I would say yes. OKR are essentially SMART goals https://en.wikipedia.org/wiki/SMART_criteria
3. It depends on how you define milestone. Usually a milestone is a gate in a phase and gate system. Would our milestones be the end of each quarter?
4. In a Scrum team, the goals should be reflected in the priority of the backlog. So, yes it should be in phabricator for those teams attempting Scrum. Kanban "ToDos" sections of the board should roughly follow this as well.
5. If a team's work is prioritized to meet their goals/OKRs then each task should have some relationship to them. The Fr-tech team is adopting sprint goals so that individual tasks have context to the whole quarter. We are also trying to maintained 3 planned sprints. Check out our backlog here: https://phabricator.wikimedia.org/tag/fundraising-backlog/

1. There is a WMF definition/explanation of OKR: Wikimedia_Engineering/OKR

Is strategy item 0.?

First time using Flow w00t!

Other terms that may be relevant (or redundant) are Epic and Roadmap.

All project management depends on some form of "progressive elaboration", in which work in the immediate future is well-detailed and less immediate work is understood more vaguely.

1. Is it valuable to have a more specific "Best Practice" cone documented?
2. If so, should there be several different cones for different situations?
3. How much variation should we expect across different teams?
4. Is there any value in using this as a kind of dashboard, and if so, how would we generate the data?

Here is a simplified visual representation of a cone of visibility.

A sample cone might look like:

• (today) Know exactly what tasks we are doing, i.e., all tasks fully detailed and prioritized.
• (this week) All tasks for the week fully detailed and prioritized.
• (2-4 weeks): 90%+ of tasks identified and prioritized
• (1-3 months): these decided. At least 50%+ of tasks known and mostly sorted (is this an objective or a health indicator?)
• (3-6 months) objectives and key results decided
• (6+ months) objectives and key results enumerated
• (1 year) possible objectives enumerated
• (beyond) No visibility other than to do some basic filtering, triaging, and/or re-checking to make sure nothing is critical. (in context of a backlog, means we'd ignore almost all the time. In context of the world of possible changes, it would mean things like watching for legal or technical changes with multi-year lead times.)

I would change the (2-4 weeks) text to "Almost all tasks are identified and prioritized", to reflect that the 90% is a rough aspiration.

At 1-3 months, I would not expect most tasks to be known and mostly sorted. I would say something more like: "Most of the work is captured in tasks or epics, and assigned a rough priority". Again, I would avoid the "50%".

In Scrum, the scope of work for each iteration is timeboxed to 1-4 weeks. Currently the VE team (and mediawiki development in general, I think) works on a weekly release cycle, although not all teams participate weekly. This has some similarity with a week-long Sprint and also some with a a week-long release cycle. Either way, VE needs to organize its backlog on a longer timeframe and there's no particular reason to use timeboxed increments. The current plan is to use prioritized "tranches", where each tranche is an internally prioritized list of tasks all related to a single goal. E.g., Tranche 1 might implement the first 1/3rd of a goal (such as rolling a new feature out to all languages); Tranche 2 might completely address one complicated problem, and then Tranche 3 might by the next 1/3rd of rolling out the new feature from Tranche 1. Tranches don't need to be the same size. Once Tranche 1 is done, Tranche 2 becomes the most important (no renumbering, just roll forward). Since the VE team has a steady flow of high-priority bug fixes, there will also be a permanent Tranche 0, and developers will not start on Tranche 1+ unless Tranche 0 is empty or otherwise fully addressed.

1. what's going to go wrong with this?
2. What is this trying to solve that Sprints solve better?
3. What does this solve better than Sprints?
4. Are tranches really an alternative to Sprints, or just a different way of sorting the Product Backlog?
5. We also have the concept of an "Unplanned" tag. How does this relate?

1. I don't see any huge problems.
2. Timeboxing can force some healthy decisions to be made.
3. Planning more than one sprint in advance seems like a fool's errand. This allows a longer time horizon of planning, without fitting neatly into sprints.
4. This could be an alternative, if developers literally work directly out of the tranches. Or it could just be a different way of sorting the backlog, if the next process step is for the PO to move tasks from tranches 0 and N into a current sprint workboard backlog. (And developers would pull tasks from there.)
5. The unplanned tag doesn't apply to the tranch board being described here. It would apply if there is also a sprint board (per #4).

I am still curious why you chose the term "tranche".

1.) My first concern would be a lack of predictability. The team would also loose the advantage of a steady rhythm. There is also something to be said for the pressure to create a shippable increment every sprint.

2.) I don't have context on the original goal of this term. However it could be accomplished with the text book application of "Sprints" a properly prioritized backlog and the concept of "Release Planning".

3.) This sounds like an attempt to create a stage and gate system. It may work in some agile frameworks. However it takes away the teams' ability to commit to work in a given time period.

4.) If you are thinking about tranches as a collection of epics, then they are more closely related to "Releases" in the classic scrum sense. But if there are time periods as well as groupings of work, you are leaning towards a traditional stage and gate process.

5.) I wanted the "Unplanned Sprint Work" tag so that I could do data analysis for my team. They have had a series of emergencies that interrupt their work. They also sometimes pull in their own work after the sprint starts. This is merely a tag for me to track these items. We will be looking at them in each retro to discuss what happened and how to improve. I'm going to be adding quite a few tags to phabricator so that I can do detailed analysis on different types of work. As trends develop, I'm going to propose fixes (and hopefully increase our velocity).