Product Development July 6, 2020

An asynchronous sprint meeting - an oxymoron or the ultimate hack?

Dima D @DimaD88

Builders unite! Need your help. As usual:)

I am launching one of the most ludicrous projects in my life. I want to build a remote-only business. Similar to the likes of GitLab, Basecamp, and a few others, I want the remote set-up to allow us to build incredible products regardless of where we are all living, which backgrounds we have, and which language is our native one.

At first, I was blocked and scared that a remote-only company is not possible in the "real world". Especially coming from a brick and mortar world (in which it is IMpossible). And then I got fed up with this "real world". As there is no central committee that sets the speed of the spin of the earth, I don't buy it that there is a central committee that defines what is possible, what is not possible. I am going to write my own rules this time.

Having said that, I am still figuring out the best way to conduct product sprint meetings at the beginning of my sprints, considering that my team: (1) doesn't necessarily speak the same language - they all can write and read in English but speaking is a challenge (2) is based in whoopingly different timezones.

Have you faced these challenges? How did you solve them? What tools do you use?

  1. 2

    Did you have a look at what Auth0, GitLab, etc wrote about being 100% remote? It seems there is more and more documentation about this. Maybe you could find some interesting insights.

    As a rule of thumb, I would say that everything needs to be considered as highly asynchronous, especially Slack like communication. Meetings should be cut, including plannings etc, especially if speaking is a challenge. Which also means that people need to be on several subjects at the same time in order to be able to work when they are waiting for an answer on something blocking them.
    Concerning meetings like the sprint planning, I noticed that it is most of the time a bunch of tasks people are more or less confident about. It frequently ends up being planned at a high level during the meeting, having 80% of the people on mute, and then, details get refined along the way by people working on it. With the help of tech leads or people with specific experience.
    So I think it could work by having small asynchronous discussions on each task, between developers the most keen to work on them. That could take place during a day to account for the time differences, and tickets would be updated along the way. At the end of the day you would have had 10 small discussions in parallel for each task, and 10 detailed tickets with sub tasks (if we speak about Jira, but I despise it :)).
    As for which tool to use, I would go for whatever works. Two people could use voip, some other, email, some other a thread in a slack channel, or even a temporary channel. I don't think it's really important, the most important is to empower people and make them owner of the tasks they will work on. Which is nearly never the case.

    1. 1

      Thanks Guillaume! Encouraging! Following your advice, I think I will force the team to block 2 hours of their time for the sprint. During these two hours, we focus just on discussing these user stories.

      I looked at Jira and it looks like overkill for me at this stage. Instead, I have opted to create my own "toolshed" kanban board in Notion. If you are curious, you can see it here:

      I have also started drafted my product development philosophy. You see my goal is to build a tech holding that builds incredible products and runs them profitable. So for me, with my first product, the process of building a product is even more important than the first product.

      1. 1

        Apparently, there is nothing Notion can't do :) It's nice, and as you said Jira is probably overkill. I would say most of the tools out there are overkill. You need nothing more than communication.
        One tool that I like a lot is GitHub. You can have projects at the organization level, user level, repository level, it really helps separating dev tasks from non-dev. But maybe it's because I am a developer and I like having everything at the same place.

        Concerning the tech holding, it seems that industrialization is the word! In this case you cannot afford to lose time on over cluttered softwares, rigid processes, etc.
        You probably know way more than me on this topic, but what I learned along the way is to always ask the "why", even to yourself.
        Why are we developing this? Why do we even need this? (Probably it's the "5 whys" technique).
        Usually you end up with interesting discussions like:
        "Why do we need to automate X. This is a loyalty marketing channel, we don't have users yet... no need to retain them."
        Spoiler alert: you can probably cut 80% of any backlog with this :D

        1. 1

          Thanks, Guillaume, I will check out GitHub. I use Notion because I can pull all the relevant information about Paudium into one source (testing, assumptions, research, etc) You can find it here: Of course, what's missing is the code:) At the same time, I don't have a stigma for any particular tool. For me, it's critical that the team actually delivers the output rather which tool they use.

          Love your take on how to approach building the holding. I am fully aligned. Wanna have a chat sometime to share ideas?

          1. 1

            Sure output > tool.
            Notion seems to be the silver bullet. It's really nice what you can do with it. It reminds me of which is focused on spreadsheets (but so cool and flexible that you would marry them, would you be some data), more document focused.

            +1 for the chat!
            You can DM me on Twitter or write me at [email protected] so we can discuss which tool to use for the chat :D

  2. 1

    (1) doesn't necessarily speak the same language - they all can write and read in English but speaking is a challenge (2) is based in whoopingly different timezones.

    I can offer one alternative that definitely works.

    • Have each teammate (starting with you) send a daily "snapshot" email, with a list of the things they're working on now, and the things they're thinking about next.


    2020-07-07 Snapshot
      - Diagram onboarding flow
      - Feature highlight - weekly summary
    Up next:
      - In-place tooltip editing
      - Trello integration examples
    1. 1

      Thank you, Lloyd! I was referring more about the initial sprint kick-off meeting. The first one where you discuss the new user stories that you want to implement.

      For daily progress, I have two slack chats: (1) Daily reports from dev team (2) Product dev chat => which is a complete tbh.