Project

General

Profile

Actions

action #105250

closed

process: daily updates: Improve our feedback time on what we do aka. "Make dailys great again"

Added by okurz over 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Target version:
Start date:
2022-01-21
Due date:
% Done:

0%

Estimated time:

Description

Motivation

Brought up in retro 2022-01-21: Many tickets in progress without any progress

Ideas

okurz would like to remind about https://progress.opensuse.org/projects/qa/wiki#What-we-expect-from-team-members

Actions #1

Updated by okurz about 2 years ago

  • Subject changed from process: daily updates: Improve our feedback time on what we do to process: daily updates: Improve our feedback time on what we do aka. "Make dailys great again"
  • Status changed from New to In Progress
  • Assignee set to okurz

I asked other people, e.g. attendees of the SUSE Agile Beer about their experiences and the common response was that there must be mandatory synchronous daily meetings. Discussed with our Scrum Master what we can do. We see mandatory daily video calls as an effective measure but we don't want to enforce the team to do this unless we have to. As a potential alternative we decided that we will run an experiment for some weeks to have next to the "alert duty" another rotating role of "moderation duty". The person doing alert duty in the next week has "moderation duty". The duty consists of ensuring https://progress.opensuse.org/projects/openqatests/wiki#How-we-work-on-tickets in particular: On a daily base ensure that we have an update from every team member that is expected to be present this day. If a person actively contributes to the daily meeting in video call or provided an update related to backlog tasks in chat then this is already ensured. We expect that this of course is an additional task with the corresponding time investment. The expected time invested per day is in the range of 3-15m, not more, so accounting for 15m-1h15m during duty week. Even in the worst case of a 30h part time worker investing said 15m every day that accounts for only 5% of weekly work time so no significant impact on contributions is expected (e.g. 1-9 tickets vs. 1-10 tickets). This new rule will be effective immediately with a wiki update and announcement over chat but of course we will support in the implementation and be gracious in the ramp-up time :)

Actions #2

Updated by okurz about 2 years ago

  • Status changed from In Progress to Feedback

put the information on the wiki but now can't read the wiki anymore. https://progress.opensuse.org/projects/qa/wiki/Tools yields "An error occurred. …Faithfully yours, nginx.", reported in #105518 . mkittler is conducting the duty role for this week, cdywan as SM should monitor on the 2nd-level if the process works. Let's see how this goes over time.

Actions #3

Updated by livdywan about 2 years ago

Inspired by @kraih I'm proposing another workflow:

Hypothesis: Ticket is stuck, assignee is silently suffering (no response in Slack, Git* or Redmine)
Proposal: Book the ticket for mob programming the next day, or whenever feasible

Doesn't really matter if someone is stuck with one or two tickets or if they can't decide what ticket to take next, but if it's impossible to respond something needs to be discussed.

Actions #5

Updated by okurz about 2 years ago

The suggestion is good for sure. It should have been clear that it was always an option to do pair-programming or mob sessions on demand anytime. I mean, we do this very often already.

As we have brought up during the meetings the past weeks and dailies we have recurring problems with people being stuck or lost or missing feedback. Sometimes plans are not properly reflected anywhere written and there is no attendance in daily meetings. Given all that we should still continue the experiment of "moderation duty" but be diligent about it to ensure that we meet what https://progress.opensuse.org/projects/qa/wiki/tools#What-we-expect-from-team-members states. If we fail with this approach then the only other option I see is to do what multiple line managers suggests, what the agile community within SUSE as well as likely most outside in the agile community suggest, which is to have mandatory daily meetings.

Actions #6

Updated by okurz about 2 years ago

Actions #7

Updated by okurz about 2 years ago

  • Tags changed from retro, process, dailies, updates to retro, process, dailies, updates, reactive work
Actions #8

Updated by okurz about 2 years ago

  • Status changed from Feedback to Resolved

I guess we have to work with daily moderation and no actual mandatory daily meetings.

Actions

Also available in: Atom PDF