action #58499
closed[experiment][6w] Have a Scrum Master for the tools team to improve team work / backlog efficiency
0%
Description
Motivation¶
Within the tools team we want to improve our team work and efficiency working on our backlog. As discussed in the weekly tools team meeting 2019-10-22 we brought up the idea of a Scrum Master once again and decided to have one as an experiment for a limited time first and review after a trial period if we would like to proceed.
Suggestions¶
- Appoint a Scrum Master
- okurz can help with the understanding of the role and processes
- Proposal by xiaojing_liu: Again have daily meetings, but voluntary, not necessarily every day
Further details¶
We are clearly not running a Scrum process. Our process can be more likened to Kanban where so far names for roles are less prescriptive. Potential alternative: Lean . We could also see the role as "process guardian" but in a very helpful, positive, supportive manner, not "process police" ;) Also see https://www.linkedin.com/pulse/what-call-scrum-master-kanban-team-mike-longin/ which suggests "team lead" which unfortunately in our work context would lead to misunderstandings. https://leankanban.com/emerging-roles-in-kanban/ suggests "Service Delivery Manager", sounds a bit bulky to me (okurz).
okurz can recommend https://youtu.be/502ILHjX9EE as a very condensed introduction into what we need to care about. https://www.youtube.com/playlist?list=PLHuCYVSRB-Poi-DZhvLhPRCcd-RDkWL7g for more tutorials.
Updated by okurz over 4 years ago
- Due date set to 2019-12-10
- Status changed from In Progress to Feedback
Mentioned the ticket to the team in Rocket.Chat , let's wait for feedback and others to pick up as I do not want to superimpose my thinking onto others.
Further ideas, questions, open points: 1. Should we appoint an architect, 2. Can we have a retro
Updated by tinita over 4 years ago
- Due date deleted (
2019-12-10) - Status changed from Feedback to In Progress
At the last job where we used Kanban, we called her "Kanban master".
Her job was to go over all issues ("cards") which are currently in progress and ask the assigned person(s) for an update.
Also she encouraged people to let others know if there was anything blocking or if they are needing help.
So in the daily standup we would go over all issues, and at the end she explicitly asked if there are blockers or help needed.
She also made sure that one person wasn't assigned to too many issues at the same time.
Our Kanban board was in Jira, and that was very helpful. We also had more columns like "Ready for Review", "Review". I guess that doesn't make sense since this is alraedy handled in GitHub for us.
I guess Redmine is not the best tool for Kanban.
Since there are team members who find the standups disruptive, maybe we can make a compromise and have it twice a week, but people should attend?
I think, having more meetings, but without an obligation to attend it won't be good for the process.
Updated by okurz over 4 years ago
tinita wrote:
Since there are team members who find the standups disruptive, maybe we can make a compromise and have it twice a week, but people should attend?
I think, having more meetings, but without an obligation to attend it won't be good for the process.
Well, dailies should not be a "status meeting" so what you mentioned as the job of a "Kanban master" is what we should do but not necessarily using daily, mandatory meetings. I guess we could cover this solely in the tickets themselves as well as chat as we decided to use for reporting on what people are busy with. I can see the value in short, disciplined dailies with mandatory attendance but let's respect the wishes of the other team members and only keep the presence in https://chat.suse.de/group/openqa-dev mandatory. I suggest to offer voluntary attendance dailies in jangouts, e.g. every day at 1100 CEST, as in before.
Updated by okurz over 4 years ago
- Due date set to 2019-12-10
@tinita seems like you overruled the conflict announcement by redmine and hence deleted the due date. Putting that back in place.
Updated by tinita over 4 years ago
okurz wrote:
Well, dailies should not be a "status meeting"
I'm just telling what kind of process we had.
As far as I know Kanban is not as strictly ruled as Scrum, but if there is a rule that a daily in Kanban should not be a status update then I would appreciate a link.
but let's respect the wishes of the other team members
I didn't mean to not respect the wishes. I thought it's ok to make suggestions and tell what has been working good for me in my previous Kanban team.
I'll go with whatever will be decided.
Updated by livdywan over 4 years ago
I think for this team at least we've found that daily update meetings aren't very productive. If we're considering "optional" stand-ups I'd suggest to define what the goal is. Because if everyone isn't part of it at least occasionally you probably won't be able to rely on it, unless we consider it one of multiple channels that are available for our communication. Ad-hoc meetings would be another in this sense, or going to someone's office where applicable. These would be optional channels available on top of the mandatory chat presence.
The proposal to have a "process elf" would actually help with that I think. The person would keep track of overall progress and how people are doing. Ideally it wouldn't matter if eg. someone likes to attend optional standups or overshares on Rocket.Chat or is more productive with ad-hoc meetings or spends more time onsite etc. Something might get stuck, in the way Tina describes it as well, but ultimately someone is there to notice. Or the other way around, someone to ask.
Updated by okurz over 4 years ago
tinita wrote:
As far as I know Kanban is not as strictly ruled as Scrum, but if there is a rule that a daily in Kanban should not be a status update then I would appreciate a link.
I don't think daily meeting should be any different in Kanban or Scrum, https://www.mountaingoatsoftware.com/agile/scrum/meetings/daily-scrum for example states "The daily scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other." . https://progress.opensuse.org/projects/suseqa/wiki#daily can describe how we could conduct dailies as well.
Updated by tinita over 4 years ago
Just for reference: https://hygger.io/blog/what-do-you-know-about-the-daily-kanban-stand-up/
That's basically how I know Kanban daily standups.
Updated by okurz over 4 years ago
- Status changed from In Progress to Feedback
Thanks for the article. I like it very much. Had a meeting with cdywan and discussed agile, Scrum, Kanban, different ideas for the team and what to do. He will follow on with this, I will then review at time.
Updated by okurz over 4 years ago
as cdywan will be offline for a bit longer, what should we do for "process facilitation"? 1. Someone else will be acting Scrum Master and steps up his game, 2. I step up, 3. I write a fancy script monitoring tickets for cycling time exceeded, number of tickets assigned too low/high, send warning emails?
Updated by Xiaojing_liu over 4 years ago
okurz wrote:
as cdywan will be offline for a bit longer, what should we do for "process facilitation"? 1. Someone else will be acting Scrum Master and steps up his game, 2. I step up, 3. I write a fancy script monitoring tickets for cycling time exceeded, number of tickets assigned too low/high, send warning emails?
All the options are good for me. If I have to choose one, I prefer the 2nd option.
Updated by okurz over 4 years ago
- Due date changed from 2019-12-10 to 2019-12-17
2019-12-17 seems to be a better choice to discuss this ticket again in the weekly team meeting.
Updated by okurz over 4 years ago
- Due date deleted (
2019-12-17) - Status changed from Feedback to Workable
- Assignee changed from okurz to livdywan
I brought this topic up for discussion in today's weekly meeting and collected feedback about having a Scrum Master. Mostly we agreed that a Scrum Master is beneficial to help ourselves with the policies and processes we define for ourselves. But we should not ask ourselves to repeat about the "status" when it is already reflected elsewhere, e.g. in tickets.
@cdywan over to you as you volunteered to stay as SM for time being. Maybe we can put some of our "team charter" or process on https://progress.opensuse.org/projects/openqav3/wiki/ where not already covered.
Updated by okurz about 4 years ago
I suggest:
- add yourself as "(SM)" on https://confluence.suse.com/display/openqa/openQA#openQA-Team
- update https://trello.com/b/v1PSNp8O/scrum-at-suse
- extend https://progress.opensuse.org/projects/openqav3/wiki/ with a "team charter"
Updated by okurz about 4 years ago
cdywan is now mentioned as "Scrum Master". Also we decided for now to not have any useful content for progress wiki. Instead I added a section "How we work" in https://confluence.suse.com/pages/diffpagesbyversion.action?pageId=192544831&selectedPageVersions=53&selectedPageVersions=51
@cdywan I suggest you add our team to https://trello.com/b/v1PSNp8O/scrum-at-suse and update accordingly. Then I think we can set this ticket to Resolved.
Updated by livdywan about 4 years ago
okurz wrote:
@cdywan I suggest you add our team to https://trello.com/b/v1PSNp8O/scrum-at-suse and update accordingly. Then I think we can set this ticket to Resolved.
Done. Thanks for helping tweak and brainstorm the bits and pieces here!