Start weekly sprint calls with a short all-hands weekly call

[flyingzumwalt]

I propose a slightly different structure for the Weekly Sprint Calls on Mondays. Could we discuss it on the upcoming call next Monday?

The proposal:

1. Start with a short all-hands weekly call (aim for 30 minutes or less. Max 1 hour)
2. Keep the Project-Specific sprint calls short and focused

Note: There are, of course, times when you need to have longer calls. For example, it totally makes sense to schedule a longer Quarterly call to discuss the roadmap, and this might happen instead of that week's sprint call, but that should be treated as an exception and scheduled in advance so people can prepare for it.

The All-Hands Call

Purpose of this call: Regular, Reliable, Short Call Where everyone who's committing on any repo under the IPFS umbrella checks in and has a chance to either call attention to particular items, to make announcements, or to seek discussion of a topic. It's also a way for casual followers to get a high-level update on the pulse of the IPFS projects without having to follow all of the sprint calls.

• Have an agenda for this call that people can add items to over the week. All agenda items need to have a person's name on them.
• Have a moderator and notetaker. Rotate these responsibilities.
• Open the meeting with a roll call
• Ask if anyone has additional agenda items
• Detailed discussions get redirected to the project-specific sprint calls, or to github, irc, etc.

The Project-Specific Sprint Calls

In short, avoid using these calls as a time for lengthy announcements or in-depth discussions. Use them to discuss the tickets people are working on and to allow brief discussion of any relevant topics or blockers. If any topics require further discussion, redirect it to either a follow-up call (ie. "Let's discuss this between the three of us immediately after the scrum."), irc, or to github issues.

I propose the structure of Scrum Standup Meetings (or a loose interpretation of it) as a possible framing for these sprint calls.

This will only become really smooth when we settle on a Project Management Process because a smooth standup call relies on having a consistent wall of tickets to refer to.

[RichardLitt]

I agree with this, and I think we can probably start this this Monday. I don't see the need for discussing how we are going to do it at length during the call, when we can read this perfectly adequate post above and come prepared for it. Taking some time to explain the format before the call really begins would be good, though!

[flyingzumwalt]

Side point for the Sprint Calls (this answers a question @whyrusleeping asked me the other week): In cases where you have an overflowing backlog, you can add a "backlog grooming" segment to your sprints where you roll up your sleves and work together to close, move, or otherwise address a concrete number of tickets each week. (ie. Squash 15 tickets each week) You keep grooming until your backlog is ready to compete at Westminster.

I've seen this approach work on multiple projects. It takes time, but it keeps the pain to a minimum.

[dignifiedquire]

Let's do this :) 👍

[daviddias]

Thank you for giving some love to our Sprint Monday calls, they definitely need some care :)

Although I love the idea of being able to get done and ready for the following week in 30 minutes, I don't believe it is actually doable without loosing the quality of the discussion, simply because we have too many things going on which require time to be discussed if we want to do any planning at all or rail in new members from the community.

• 👍 for having agendas prepared beforehand
• 👍 for notetaker
• 💯 for project specific calls and technical discussions that need to happen deferred/allocated for a slot during Monday

If we want to maximize efficiency and start grouping more of this meetings in Monday (instead of scattered over the week), it is important to remind everyone how no one should miss them (i.e. Don't schedule things with the expectation that the discussion can be moved to another day)

[flyingzumwalt]

30 minutes is definitely aspirational. In the short term, the all-hands calls will probably be an hour long. I just want to encourage the idea that we can and should keep these synchronous meetings short because most of the important discussion happens in github issues, Pull Requests, etc. and actually should happen in those asynchronous forums as much as possible.

Good point about making the meeting times for other calls predictable. I've got some ideas on that.

I'm going to work on a proposed template meeting agenda/notes document.

[flyingzumwalt]

Is anyone interested in looking at the PM README with me to see what information is accurate, inaccurate, aspirational, outdated, etc? @RichardLitt @haadcode ?

[RichardLitt]

@flyingzumwalt I am the best for this; and yes, I'm happy to do this.

[jbenet]

• 👍 to the suggestions above
• 👍 to starting with an all hands call (we felt the need for this many times)
• 👍 to moving long discussions out of the project calls. that can happen separately. I think keeping these to under 30min is critical. everyone has been complaining about the length of monday calls, and it's no use to people if we keep avoiding these days.

With everyone around on Mondays, we can break out to whatever other discussions need to happen, as they need to happen.

@diasdavid i think we can make time and space to cover the much needed f2f time separately from these project management calls. these main calls are NOT to introduce new people to the project, not to explain things, nor to discuss and find solutions to problems. I know we've been using them for that, but that's not the right venue. These calls are only for project management upkeep -- discuss what got done the week prior and discuss the upcoming week, etc. The other stuff can happen separately. You can even schedule that time specifically, even on mondays, too, but separate from the sprint call.

Note, too, that under the Kanban approach suggested elsewhere, most of these calls would completely disappear anyway, in favor of more real-time support during the week. (which is OK because these calls are NOT meant to be introductory, these calls are only for project management).

[daviddias]

• Proposal from last Monday Sprint: Allocate a time for demos during the All Hands

[daviddias]

We've adopted this 🎉 Thank's y'all :)
closing the issue

[RichardLitt]

This should be noted in the README for this repo. Reopening to track that.

[flyingzumwalt]

Technical point: "Add info about weekly sprints to the readme" should be a new issue. Otherwise you end up with open issues whose titles don't match the work that needs to be done. We've satisfied the proposal that this issue's title and description call for, so the issue should stay closed.

Also, we did write up a description of the weekly calls in the Draft PM Document here: https://github.com/ipfs/pm/blob/master/drafts/Project%20Management%20Process.md#weekly-updates. I think we intended to update the Readme after we ratified the PM Document so both files would be consistent. We didn't realize the PM Doc would take months to ratify.

[RichardLitt]

We've satisfied the proposal that this issue's title and description call for, so the issue should stay closed.

I know where you're coming from, but I don't think we have solved this issue. Part of satisfying this issue is making sure that we've covered how people know about the process, which involves updating the README so that newcomers know we do this. Including documentation as part of our process for closing issues is important, because otherwise it depends on someone else remembering later to write up another issue referring to this one.

You're right that we have a writeup in the Draft PM doc. We can edit the README after that is merged (aside: what is happening with that?). For now, I am going to make a PR to do this at the moment so that this issue doesn't stay open much longer.

[flyingzumwalt]

Is that the convention with code-related issues? The issue can't be closed until the documentation is added? That makes sense to me as long as we're consistent.

I'm fine with updating the Readme now, since we are already following that practice. I just wanted to make sure you knew we already have a copy of that text lying around in case you want to re-use it.

[RichardLitt]

That's a valid point, but this repository isn't code - it's documents. View the documents as the code which allows us to function. If we agree on something, and it isn't written down in a README somewhere, then the new version of the code won't run well as new input is added. We need to make sure that people coming to this repo for the first time don't get lost and confused about new practices. As such, documentation really is part of the issue - because that's how we add to our process here.

Updated the README - not the biggest change in the world, but should be able to close this issue as it is now somewhere explicitly.

[flyingzumwalt]

Thank you for clarifying. I get it now.

[RichardLitt]

No problem. :) Thanks for asking! Looking forward to the PM document being worked on, too.

[daviddias]

Well, seems that everything got clarified and done, closing now :)