Wikimedia Cloud Services team/Team work board practices
 | This document is not describing the current practices and should be updated. Some information on the current practices can be found in wikitech:Wikimedia Cloud Services team/EnhancementProposals/Decision record T322756 WMCS Kanban board |
Our team organizes much of our work tickets (Phabricator tasks) on what looks and feels like a Kanban board. We don't use it entirely like Kanban, but we do use it to organize and think about our work in different ways.
The practices below are subject to review and change. This page should be kept up to date by the team when changes happen. The board is on Phabricator at phab:project/board/2774
For reference on how to use the technology behind the board, see Phabricator/Project management#Boards.
Board Column Overview
[edit]Columns must have meanings and agreed upon practices to be useful to us all
- Inbox - Kanban users also call this the "backlog". Basically everything that hasn't been touched or is not currently considered priority, somehow controversial or actively being worked on is here. This is the default column when you tag something with
cloud-services-team (Kanban) - Important - Tasks in this column are considered important to work on as soon as there is time by someone on the team. If someone disagrees with that designation, they can move it into "Needs discussion"
- Doing - Whatever is being worked on should be here, even if just for a few minutes. This way we all know what is actually in flight. Tasks should be assigned and grouped here according to assignee, understanding that sometimes there's really more than one person working a ticket even if Phab doesn't let us show that. Part of the idea here is so that we can help each other more effectively anyway. If we know what is active, we know what is worth commenting on if we found out something to share.
- Each person should have no more than 5 items under Doing if possible
- In total, there should not be more than 22 items in Doing. As is, someone has too many tasks if it's that many anyway. The limits are to get a visual idea of how burdened we all are, understanding that not all tasks are equal.
- The nature of much of our work makes the usage of this column somewhat uneven at this time. Exactly how to use it is something to possibly revisit.
- Clinic Duty - Items specifically slated to be worked on by the on-call or that came up during the on call for quick work.
- Needs discussion - Placing a task here signifies that this is to be an agenda item in our next meeting for whatever reason (and is not ready for immediate work)
- Blocked - self explanatory, but this should be automatically the same as the blocks section of our meeting pad. If you use this column, you should probably still raise the issue in our weekly etherpad.
- Done - Ideally this will be an automated column. It is currently the most uncertain part of the board in terms of usefulness.
- Epics - These tickets generally don't really get "worked on" on their own, but they are often linked to goals or a source of future goals. They should be tracked here so we kind of have some idea of what are non-controversial, ideally in priority order. This column is just to surface them for easy reference.
- Graveyard - For tickets that we are not so far going to work on or never going to work on, but are things we'd like to keep an eye on.
Meeting impact of the board
[edit]- Needs discussion is an agenda item in itself and should ideally be cleared by the end of the meeting unless more information is required for the next time we talk
- Blocks column is the same as blocks in the etherpad
- anything that remains in Doing from week to week could also be an automatic discussion item to help surface things that are lagging and might benefit from pairing, added assistance or escalation -- that said, this idea has not been implemented since we haven't had a good way to do it
- Strictly speaking, this would be a point-in-time representation of what the etherpad actually says once a week. Theoretically, the etherpad is redundant except insofar as it can be copied into the SRE meeting pad and the fact that it is a snapshot of what the board should have said on that Tuesday. The biggest exception is the outgoing updates, which is for external consumption really.
Daily Workflow
[edit]- check the inbox in case anything should be in "Important"
- ensure that Doing actually represents what you are doing today as best as possible
- shuffle things if needed
Clinic Duty
[edit]The main change here is that there is some assumption that some items might load up the Clinic Duty column, so fewer should be in the Doing column for the Clinic Duty person (or the Clinic Duty person might need some help to get important things done if there's a lot going on--not really always predictable).
Comments
[edit]The most important elements of Kanban for our team are limiting and providing visibility to work. This should help prevent important things from going unnoticed, people from being overtaxed and opportunities for teamwork from being missed. Many Kanban-like styles focus on sprints and time limited tasks. While that is useful discipline, it is far easier to apply to development than operations because of the nature of the beast.
We should mentally think of items in Doing as discrete and achievable tasks in a general sense. If they are prone to great lengths of time and lots of work, perhaps making them an epic with split up subtasks will work better for the board.