Skip to main content

Scrum Methodology & Meeting Cadence

We follow an adapted Scrum framework to manage our 6‑week development cycle. This approach gives us tight feedback loops, clear daily progress visibility, and consistent alignment with our client—without drowning the team in unnecessary meetings.

Meeting Schedule​

MeetingDayTimePlatformAttendees
Internal Standup 1Monday10:00 AMGoogle MeetWhole team
Internal Standup 2Tuesday10:00 AMGoogle MeetWhole team
Client SyncWednesday1:30 PMGoogle MeetWhole team + Client
Async CommunicationDailyOngoingWhatsAppWhole team

Why This Schedule Works​

1. Early‑week rhythm without over‑meeting​

  • Monday sets the tone for the week: we align on priorities, review the sprint backlog, and identify any immediate blockers before diving into work.
  • Tuesday is a rapid checkpoint—only 24 hours later—so if a task is slipping or a dependency is blocked, we catch it early and can re‑plan before the week gets away from us. This avoids the classic "Friday panic" where problems sit unnoticed for days.

2. Client feedback lands at the perfect time​

  • The Wednesday 1:30 PM client sync is the centrepiece of our week.
  • Because it falls mid‑week, the client sees tangible progress from Monday/Tuesday, and any feedback they give can be actioned on Thursday and Friday—giving us two full working days to pivot, clarify, or add polish before the next Monday standup.
  • The timing (1:30 PM) was chosen specifically because it fits best with our client's existing schedule, showing that we respect their time as much as our own.

3. Async communication keeps the flow going​

  • Formal standups are great for strategy and blockers, but they shouldn't become a bottleneck for quick questions. WhatsApp handles the day‑to‑day:
    • Quick bug reports / screenshots.
    • "Does this API contract look right to you?"
    • Heads‑ups about PRs ready for review.
    • Sharing useful links or resources.
  • This keeps our Google Meet time focused on decisions rather than status updates, making every meeting more efficient.

4. Time‑boxed for deep work​

  • Both internal standups start at 10:00 AM and are strictly time‑boxed to 15–20 minutes.
  • This leaves the rest of the morning (and the entire afternoon) clear for uninterrupted coding, design, and testing—exactly when our team is most productive.
  • A short, disciplined standup is better than a long, wandering one. We follow the classic three‑question format:
    • What did I complete yesterday?
    • What am I working on today?
    • What blockers do I have?

5. Shared visibility across the whole team​

  • Everyone attends the client meeting, not just the lead. This means:
    • The client sees the whole team, building trust and rapport.
    • Every team member hears feedback first‑hand, reducing miscommunication.
    • We all share the same understanding of what "done" looks like from the client's perspective.

6. Convenience as a deliberate choice​

  • We explicitly chose these times because they are the most convenient for both the team and the client.
  • Monday/Tuesday mornings are free of overlapping lectures for most of us.
  • Wednesday afternoons avoid the client's busy morning blocks.
  • Convenience isn't a "nice‑to‑have"—it directly increases attendance, engagement, and the quality of our collaboration. When people aren't rushing from another meeting or skipping lunch, they contribute more meaningfully.

Scrum Master: Benjamin​

Benjamin serves as our Scrum Master. His responsibilities are:

  • Facilitating the Monday and Tuesday standups—ensuring they start on time, stay within the 20‑minute limit, and that every team member has a chance to speak.
  • Preparing the agenda for the Wednesday client sync (collecting demo notes, deciding which features to showcase, and summarising any questions for the client).
  • Maintaining the sprint backlog (tracking which stories are in progress, done, or blocked).
  • Removing blockers—for example, following up on Gitea permissions, debugging CI pipeline failures, or coordinating cross‑team dependencies.
  • Enforcing the definition of done, ensuring PRs are properly reviewed and tests pass before merging into develop.
  • Acting as the liaison between the team and the client for any scheduling or expectation‑setting conversations.

Benjamin is not a "boss" or a task‑assigner; he is a servant leader who enables the rest of the team to stay focused and productive.

This methodology will be reviewed after Sprint 1 to see if any adjustments (e.g., moving the Tuesday standup to late Friday) would better suit our evolving workflow. For now, it gives us a solid, proven rhythm to build from.