Here is a starting point for discussion about what team meetings we should have, moving forward. I'm not stuck on any of these specifics. It's just easier to have a candidate proposal to pick apart, rather than starting a group discussion completely from scratch. I have probably missed some as well.
So feel free to question or challenge, or to propose tweaks to or deletions of, any of these. Or propose more meetings. We might end up with a panel of meetings completely different from what you are about to read. But here goes...
1. Full-team checkin (weekly, 25-50 minutes)
This is very similar to the meeting we have been having Mondays and Thursdays, but with less of a "here is my status" focus, and more of a "here is what other people might find interesting". The Scrum-of-scrums stuff probably wouldn't be here, and definitely no looking at workboards. The primary purposes are team-building and information-spreading.
2. "Sprint" planning (weekly, 25-50 minutes)
Since we won't be using timeboxed sprints, the frequency of this meeting is pretty arbitrary. The main goal is to make sure the "To do" columns in the sprint boards never go empty. This is where Dan (and Moiz) would propose stories to move from the product backlog into the individual sprint boards. Some combination of tech leads would attend, and would give rough estimates, raise issues about incomplete specs, suggest alternate prioritizations, etc. Other developers could be included, but most likely would be optional (and perhaps very optional). It's not clear to me to what degree this meeting should (or could) be divided up into segments for each sub-team.
3. Daily standup (almost-daily, 5-15 minutes)
I think it is useful for the subteams to have some form of meeting more than twice per week. But to avoid having "too many" meetings, I'll propose the option of doing these on IRC. I would also propose that each sub-team schedule its own separate daily standup, but obviously not at overlapping times. I'm totally open to individual subteams deciding they don't need daily standups.
These should probably follow standard daily scrum format, unless there is a reason not to: Each developer (or other information worker) would say what they completed since the last standup, what they expect to accomplish by the next one, and if they are blocked by anything. The main benefits of this are team cohesion, daily focus on what is important, and quickly identifying blockers.
4. Showcase (biweekly?, 25-50 minutes)
This is a chance for subteams to proudly demonstrate what they have accomplished. This could be opened up to folks outside S&D, but those details should be worked out. Especially in the near term, I'm not sure what frequency would be best. The purpose is twofold: It's always fun to show what you have done, and it's helpful to other stakeholders to really see what S&D is up to.
5. Retrospective (biweekly?, 25-50 minutes)
As we settle in, these retrospectives are likely to become shorter, and we will be able to go deeper on a smaller number of issues, and really discuss possible solutions. These could be every 3 weeks or monthly, but I would prefer to have them more often, but shorter. The purpose, of course, is continual improvement.
6. Technical deep-dives (purely as needed)
I haven't seen a case for holding a standing meeting time open for these, especially now that the team has 5 different but sometimes-overlapping subteams.
7. Product backlog grooming (TBD)
Note that this is purely at the product backlog level, not at the sprint board level. It is not clear to me who would be involved helping Dan keep the many product backlog items clearly organized.
8. Front-end/back-end coordination (TBD)
I feel like some combination of Moiz/Dan/TechLead would be helpful here, but don't yet have a clear picture of what it would be.
9. Other
Of course, there would also be various strategy-level and operational meetings between various combinations of Wes, Moiz, Dan, and Oliver. I'm especially unclear on what (if any) research/data-related standing cross-sub-team meetings we should have. And this doesn't count all the recurring one-on-ones, which are also valuable.
What else did I forget?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
On Thu, May 7, 2015 at 3:02 PM, Kevin Smith ksmith@wikimedia.org wrote:
Here is a starting point for discussion about what team meetings we should have, moving forward. I'm not stuck on any of these specifics. It's just easier to have a candidate proposal to pick apart, rather than starting a group discussion completely from scratch. I have probably missed some as well.
So feel free to question or challenge, or to propose tweaks to or deletions of, any of these. Or propose more meetings. We might end up with a panel of meetings completely different from what you are about to read. But here goes...
- Full-team checkin (weekly, 25-50 minutes)
This is very similar to the meeting we have been having Mondays and Thursdays, but with less of a "here is my status" focus, and more of a "here is what other people might find interesting". The Scrum-of-scrums stuff probably wouldn't be here, and definitely no looking at workboards. The primary purposes are team-building and information-spreading.
This seems like the showcase meetings.
I think the only reason to keep this around is to make sure we feel like a team. Its nice to hear everyone's voice but why not rely on the others for this?
- "Sprint" planning (weekly, 25-50 minutes)
Since we won't be using timeboxed sprints, the frequency of this meeting is pretty arbitrary. The main goal is to make sure the "To do" columns in the sprint boards never go empty. This is where Dan (and Moiz) would propose stories to move from the product backlog into the individual sprint boards. Some combination of tech leads would attend, and would give rough estimates, raise issues about incomplete specs, suggest alternate prioritizations, etc. Other developers could be included, but most likely would be optional (and perhaps very optional). It's not clear to me to what degree this meeting should (or could) be divided up into segments for each sub-team.
This one is fine. It should start as 50 minutes I think and we should try to shrink it if possible.
Note that two 50 minute meetings back to back is 300% better than three 25 minute meetings scattered throughout the day.
- Daily standup (almost-daily, 5-15 minutes)
I think it is useful for the subteams to have some form of meeting more than twice per week. But to avoid having "too many" meetings, I'll propose the option of doing these on IRC. I would also propose that each sub-team schedule its own separate daily standup, but obviously not at overlapping times. I'm totally open to individual subteams deciding they don't need daily standups.
These should probably follow standard daily scrum format, unless there is a reason not to: Each developer (or other information worker) would say what they completed since the last standup, what they expect to accomplish by the next one, and if they are blocked by anything. The main benefits of this are team cohesion, daily focus on what is important, and quickly identifying blockers.
Daily is probably going to be hard for some teams unless we have some asynchronous process. France and SF just don't overlap enough to do something synchronous daily.
- Showcase (biweekly?, 25-50 minutes)
This is a chance for subteams to proudly demonstrate what they have accomplished. This could be opened up to folks outside S&D, but those details should be worked out. Especially in the near term, I'm not sure what frequency would be best. The purpose is twofold: It's always fun to show what you have done, and it's helpful to other stakeholders to really see what S&D is up to.
Tomasz's proposal to do them monthly made more sense to me.
- Retrospective (biweekly?, 25-50 minutes)
As we settle in, these retrospectives are likely to become shorter, and we will be able to go deeper on a smaller number of issues, and really discuss possible solutions. These could be every 3 weeks or monthly, but I would prefer to have them more often, but shorter. The purpose, of course, is continual improvement.
Same comment as #4. Can we just line up the showcase and the retrospective on the same day one after the other?
- Technical deep-dives (purely as needed)
I haven't seen a case for holding a standing meeting time open for these, especially now that the team has 5 different but sometimes-overlapping subteams.
+1. We haven't needed this for a while.
- Product backlog grooming (TBD)
Note that this is purely at the product backlog level, not at the sprint board level. It is not clear to me who would be involved helping Dan keep the many product backlog items clearly organized.
Its not clear to me how this is different than the "sprint" planning meeting. I expect we're just going to be pulling stuff form the top of some list into the sprint when we need it.
- Front-end/back-end coordination (TBD)
I feel like some combination of Moiz/Dan/TechLead would be helpful here, but don't yet have a clear picture of what it would be.
Ad hoc like the technical deep dives?
9. Other
Of course, there would also be various strategy-level and operational meetings between various combinations of Wes, Moiz, Dan, and Oliver. I'm especially unclear on what (if any) research/data-related standing cross-sub-team meetings we should have. And this doesn't count all the recurring one-on-ones, which are also valuable.
The showcase is a good time for that.
Its probably worth mentioning that those Monday/Thursday meetings used to be our standup. When it was just WDQ or just WDQ and Cirrus they worked just like a standup with a post-scrum time pre-booked. The twice a week frequency is what worked for Stas, James, Jan, and I for WDQ and we just stuffed everyone else in the meeting when the search vertical started because it was already there. In fact the round the room style of updates we do is literally what the standup should be, only it takes us 20 minutes instead of 15.
My proposal is to drop the full team meeting, make the standups per-subteam, and let the subteams decide how frequently and how they want them. My guess is Yuri and Max talk enough as is and won't need it. Cirrus and WDQ can go back to Mon/Thr but drop the meeting to 15 minutes instead of an hour. And when the team grows we can change that too. Make the retrospectives and showcases abut one another and only once per month. The snag with this proposal is that we no longer have "team" time every week - we only all get together two hours a month. Maybe add another hour half way between the retrospectives and call that the full team meeting.
Nik
Thanks for the detailed reply, Nik!
On Fri, May 8, 2015 at 8:43 AM, Nikolas Everett neverett@wikimedia.org wrote:
- Full-team checkin (weekly, 25-50 minutes)
This seems like the showcase meetings.
I see them as quite different. My vision of the showcase (which could be quite different from anyone/everyone else's) would be that it would consist of presentations, and would focus on demonstrations (or documents), not discussion (although obviously things would be discussed). Two or three people or teams might each take 15 minutes showing something off, and most attendees would be "audience", not "presenters".
The team checkin would be a mix of water-cooler talk and team issues like "Who is going to the hackathon?" or "Hey, we'll be releasing X next week".
That is not to argue that we necessarily need both. Just that I see them as relatively non-overlapping.
I think the only reason to keep this around is to make sure we feel like a team. Its nice to hear everyone's voice but why not rely on the others for this?
If we want the entire vertical to feel like "one team" (which is what I heard from several people), then I think some kind of "team" meeting weekly is pretty valuable. If the whole team is meeting weekly for other reasons, that could fulfill that purpose.
- "Sprint" planning (weekly, 25-50 minutes)
This one is fine. It should start as 50 minutes I think and we should try to shrink it if possible.
Makes sense to me. And we have already proven that we are capable of ending meetings early, rather than always dragging them out to their full allotted time.
- Daily standup (almost-daily, 5-15 minutes)
Daily is probably going to be hard for some teams unless we have some asynchronous process. France and SF just don't overlap enough to do something synchronous daily.
I'm fine with each subteam figuring out what will work for them. You're right that some 2-person teams probably don't need anything, and some of the other teams might work well with 2x per week. Email is also an option for daily contact, when synchronous is not an option.
Personally, as a developer, I found value in having regular checkins, because it helped me stay on track. Was I not meeting my commitments because I was getting dragged into other projects? Too many meetings? Distracted by shiny objects? Surprised by unexpected issues? Or, in cases where I was working efficiently toward my commitments, it was nice to take a scheduled moment and consciously say: "Yup, everything is on target."
- Showcase (biweekly?, 25-50 minutes)
Tomasz's proposal to do them monthly made more sense to me.
Sounds fine. The main reason I mentioned biweekly is that in a pure scrum environment, they do these at the end of every sprint, which is often 2 weeks. But especially given the nature of the work this team is doing right now, monthly makes sense.
- Retrospective (biweekly?, 25-50 minutes)
Same comment as #4. Can we just line up the showcase and the retrospective on the same day one after the other?
Monthly feels a bit infrequent to me, but I'm open to trying it.
An alternative to the back-to-back would be to have a meeting every two weeks, and alternate between a showcase and a retrospective. Just a thought.
- Technical deep-dives (purely as needed)
+1. We haven't needed this for a while.
Cool.
- Product backlog grooming (TBD)
Its not clear to me how this is different than the "sprint" planning meeting. I expect we're just going to be pulling stuff form the top of some list into the sprint when we need it.
The sprint planning is about pulling work from the product backlog into the sprint backlog. This grooming activity (which would not necessarily be in the form of a meeting) is all about the product backlog, triaging new issues, making sure task titles are clear, setting roadmap-level priorities, and figuring out what tasks are likely to be candidates at the next sprint planning meeting.
- Front-end/back-end coordination (TBD)
Ad hoc like the technical deep dives?
Maybe. I suspect this one will change over time, as our UX team is built up.
- Other
Of course, there would also be various strategy-level and operational meetings between various combinations of Wes, Moiz, Dan, and Oliver. I'm especially unclear on what (if any) research/data-related standing cross-sub-team meetings we should have. And this doesn't count all the recurring one-on-ones, which are also valuable.
The showcase is a good time for that.
You are proposing having a combined Showcase+Cross-sub-team issues meeting? Interesting, but I a wary of combining those two unrelated topics. Perhaps this goes back to our differing interpretations of the showcase.
In fact the round the room style of updates we do is literally what the standup should be, only it takes us 20 minutes instead of 15.
Well, plus our current twice-weeklies give a voice to UX, Data, PM, VP, etc, whereas a standup would typically be developers only. But yes, they are currently quite similar in structure.
More thoughts (from anyone/everyone)?
Kevin
On Fri, May 8, 2015 at 1:04 PM, Kevin Smith ksmith@wikimedia.org wrote:
Thanks for the detailed reply, Nik!
On Fri, May 8, 2015 at 8:43 AM, Nikolas Everett neverett@wikimedia.org wrote:
- Full-team checkin (weekly, 25-50 minutes)
This seems like the showcase meetings.
I see them as quite different. My vision of the showcase (which could be quite different from anyone/everyone else's) would be that it would consist of presentations, and would focus on demonstrations (or documents), not discussion (although obviously things would be discussed). Two or three people or teams might each take 15 minutes showing something off, and most attendees would be "audience", not "presenters".
The team checkin would be a mix of water-cooler talk and team issues like "Who is going to the hackathon?" or "Hey, we'll be releasing X next week".
That is not to argue that we necessarily need both. Just that I see them as relatively non-overlapping.
Yeah that is what I expected as well. Showcase is for demo as described and Full team is for state of search from multiple teams.
I think the only reason to keep this around is to make sure we feel like
a
team. Its nice to hear everyone's voice but why not rely on the others
for
this?
If we want the entire vertical to feel like "one team" (which is what I heard from several people), then I think some kind of "team" meeting weekly is pretty valuable. If the whole team is meeting weekly for other reasons, that could fulfill that purpose.
Yes.
- "Sprint" planning (weekly, 25-50 minutes)
This one is fine. It should start as 50 minutes I think and we should
try to
shrink it if possible.
Makes sense to me. And we have already proven that we are capable of ending meetings early, rather than always dragging them out to their full allotted time.
- Daily standup (almost-daily, 5-15 minutes)
Daily is probably going to be hard for some teams unless we have some asynchronous process. France and SF just don't overlap enough to do something synchronous daily.
I'm fine with each subteam figuring out what will work for them. You're right that some 2-person teams probably don't need anything, and some of the other teams might work well with 2x per week. Email is also an option for daily contact, when synchronous is not an option.
Personally, as a developer, I found value in having regular checkins, because it helped me stay on track. Was I not meeting my commitments because I was getting dragged into other projects? Too many meetings? Distracted by shiny objects? Surprised by unexpected issues? Or, in cases where I was working efficiently toward my commitments, it was nice to take a scheduled moment and consciously say: "Yup, everything is on target."
- Showcase (biweekly?, 25-50 minutes)
Tomasz's proposal to do them monthly made more sense to me.
Sounds fine. The main reason I mentioned biweekly is that in a pure scrum environment, they do these at the end of every sprint, which is often 2 weeks. But especially given the nature of the work this team is doing right now, monthly makes sense.
- Retrospective (biweekly?, 25-50 minutes)
Same comment as #4. Can we just line up the showcase and the
retrospective
on the same day one after the other?
Monthly feels a bit infrequent to me, but I'm open to trying it.
An alternative to the back-to-back would be to have a meeting every two weeks, and alternate between a showcase and a retrospective. Just a thought.
Well if the idea is they are both sprint related -- I like stacking them after the sprint as suggested by Nik and keeping them to the lighter side time wise but blocking the 50 for both. No demos... straight to retro where we comment on the lack of demo-able things :). If you want to demo you need to let Kevin know by the day before so he can cancel or give appropriate time estimates? Finish early we get a reward of more time to ourselves.
- Technical deep-dives (purely as needed)
+1. We haven't needed this for a while.
Cool.
- Product backlog grooming (TBD)
Its not clear to me how this is different than the "sprint" planning meeting. I expect we're just going to be pulling stuff form the top of
some
list into the sprint when we need it.
The sprint planning is about pulling work from the product backlog into the sprint backlog. This grooming activity (which would not necessarily be in the form of a meeting) is all about the product backlog, triaging new issues, making sure task titles are clear, setting roadmap-level priorities, and figuring out what tasks are likely to be candidates at the next sprint planning meeting.
- Front-end/back-end coordination (TBD)
Ad hoc like the technical deep dives?
Maybe. I suspect this one will change over time, as our UX team is built up.
- Other
Of course, there would also be various strategy-level and operational meetings between various combinations of Wes, Moiz, Dan, and Oliver. I'm especially unclear on what (if any) research/data-related standing cross-sub-team meetings we should have. And this doesn't count all the recurring one-on-ones, which are also valuable.
The showcase is a good time for that.
You are proposing having a combined Showcase+Cross-sub-team issues meeting? Interesting, but I a wary of combining those two unrelated topics. Perhaps this goes back to our differing interpretations of the showcase.
If we have not covered it in the other meetings I would be surprised. I think external showcases for other orgs or company brown bags maybe the exception and we'd do those as we get close to having something viable for release to generate excitement or elicit feedback before release. Dan would typically be the instigator with support from various teams per feature.
In fact the round the room style of updates we do is literally what the
standup should be, only it takes us 20 minutes instead of 15.
Well, plus our current twice-weeklies give a voice to UX, Data, PM, VP, etc, whereas a standup would typically be developers only. But yes, they are currently quite similar in structure.
More thoughts (from anyone/everyone)?
Kevin
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
On Fri, May 8, 2015 at 10:54 AM, Wes Moran wmoran@wikimedia.org wrote:
Kevin wrote:
An alternative to the back-to-back would be to have a meeting every two weeks, and alternate between a showcase and a retrospective. Just a thought.
Well if the idea is they are both sprint related -- I like stacking them after the sprint as suggested by Nik
But we weren't planning to have sprints. At least, that has been my understanding. I thought we would just have rolling work, where each task gets done when it gets done.
Now, we could change that plan, and instead try having "non-commitment" iterations. Every 2 weeks (or 1 or 3), we could gather a subteam, and lay out the work we think/hope might get done in that iteration. However, unlike a true Scrum timeboxed sprint, the team would not be committing to that work. It would merely be a good faith best guess.
Advantages: Rhythm. Potential to measure velocity. Clear time point for demos and retrospectives. Moves us toward Scrum.
Disadvantages: Would require some level of task estimation. Might be demoralizing to not finish what was hoped. Forces the PO to predict 2 weeks at a time. Might combine the worst of Kanban with the worst of Scrum.
I'm especially interested to hear from developers on this one. It's a great, valid question.
Kevin
In the interest of keeping things moving forward, I have come up with a new proposal that takes all the input so far into consideration. You can see it as part of the larger "process" proposal, which I will announce in a separate email (so it doesn't get buried).
If anyone wants to continue this discussion here as well, then by all means please do so.
Thanks,
Kevin Smith Agile Coach Wikimedia Foundation
Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.
On Fri, May 8, 2015 at 11:44 AM, Kevin Smith ksmith@wikimedia.org wrote:
On Fri, May 8, 2015 at 10:54 AM, Wes Moran wmoran@wikimedia.org wrote:
Kevin wrote:
An alternative to the back-to-back would be to have a meeting every two weeks, and alternate between a showcase and a retrospective. Just a thought.
Well if the idea is they are both sprint related -- I like stacking them after the sprint as suggested by Nik
But we weren't planning to have sprints. At least, that has been my understanding. I thought we would just have rolling work, where each task gets done when it gets done.
Now, we could change that plan, and instead try having "non-commitment" iterations. Every 2 weeks (or 1 or 3), we could gather a subteam, and lay out the work we think/hope might get done in that iteration. However, unlike a true Scrum timeboxed sprint, the team would not be committing to that work. It would merely be a good faith best guess.
Advantages: Rhythm. Potential to measure velocity. Clear time point for demos and retrospectives. Moves us toward Scrum.
Disadvantages: Would require some level of task estimation. Might be demoralizing to not finish what was hoped. Forces the PO to predict 2 weeks at a time. Might combine the worst of Kanban with the worst of Scrum.
I'm especially interested to hear from developers on this one. It's a great, valid question.
Kevin
Hi!
Daily is probably going to be hard for some teams unless we have some asynchronous process. France and SF just don't overlap enough to do something synchronous daily.
I think we also don't have enough things to say for daily. E.g. I suspect it would be mostly "still working on backlog". And given there are other meetings too, it may not be necessary.
I think something like twice a week would be enough, maybe as the team grows if we figure out we got more content we can increase the frequency.
Same comment as #4. Can we just line up the showcase and the retrospective on the same day one after the other?
I agree, great idea for having monthlies together if they're in the same week.
month. The snag with this proposal is that we no longer have "team" time every week - we only all get together two hours a month. Maybe add another hour half way between the retrospectives and call that the full team meeting.
I'd still prefer to have full team meeting at least bi-weekly - maybe half of them one kind, half of them another kind, but the month is a long time and if we meet only once a months as a team, it may be too infrequently to really feel there's a team.
wikimedia-search@lists.wikimedia.org