AgilePM Practitioner study materials
AgilePM Practitioner study resources

Facilitated Workshop or Daily Stand-up? Choosing Techniques

AgilePM Practitioner · Put your knowledge to work in context.

All case studies

Facilitated Workshop or Daily Stand-up? Choosing Techniques

A distributed team of 9 (4 onshore, 5 offshore across two time zones) is mid-delivery. The project manager has been running a 60-minute daily stand-up with all 9 attendees to 'keep everyone aligned'. Attendance is patchy for the offshore members, who join at 10pm local time; two have stopped attending. Requirements are still emerging for a complex pricing engine, and the business ambassador is frustrated that decisions made in workshops are 're-litigated' in the stand-up. The team leader wants to replace the stand-up with written updates and introduce a facilitated workshop for the pricing rules. The technical coordinator worries that written updates will hide blockers. The next timebox starts in 5 days.

1. Evaluate the current stand-up and recommend how AgilePM techniques should be applied here.

Read the worked answer

The current stand-up violates the intent of the technique. A daily stand-up in AgilePM is a short, focused team coordination event (typically ~15 minutes) for the delivery team to surface progress, plans and blockers - not a 60-minute all-hands alignment meeting, and not a forum for re-deciding requirements.

Problems:

  • Wrong length and audience: 60 minutes with 9 people across time zones is a status meeting. AgilePM's 'Collaborate' and 'Demonstrate control' principles favour frequent, lightweight communication.
  • Time-zone inequity: forcing offshore members to attend at 10pm guarantees disengagement - two have already dropped out. That is a collaboration failure, not a discipline problem.
  • Decision leakage: requirements decisions belong in facilitated workshops with the business ambassador, not in the stand-up. Re-litigating in the stand-up undermines the workshop output and wastes the team's time.

Recommendations:

  • Shorten and refocus the stand-up: ~15 minutes, delivery team only, focused on progress/plan/blockers.
  • Split by time zone: run two short stand-ups (onshore and offshore) with a written handover, or rotate the time so no group is permanently disadvantaged.
  • Use a facilitated workshop for the pricing engine requirements - this is the correct AgilePM technique for collaborative elicitation and decision-making with business roles.
  • Record workshop decisions so they are not re-opened; the business ambassador should own sign-off.
  • Keep a visible blocker log so blockers surfaced in stand-ups are tracked, addressing the technical coordinator's concern.

2. The technical coordinator argues written updates will hide blockers. How would you design the replacement to address this while respecting AgilePM?

Read the worked answer

The concern is valid but the solution is design, not rejection.

Design the replacement so blockers cannot hide:

  • Written update has a mandatory 'blockers/impediments' field, and the team leader reviews it before the working day starts. A blocker is escalated the same day, not at the next meeting.
  • Keep a live, visible blocker board (physical or digital) that anyone can add to and that the team leader and technical coordinator review daily. Visibility, not meeting attendance, is what prevents blockers being lost.
  • Timebox the written update: a fixed daily cut-off, so it is a rhythm rather than an optional chore.
  • Retain a short synchronous touchpoint - a 15-minute stand-up at a rotating time, or a brief onshore/offshore pairing - so the technical coordinator has a live channel for technical blockers.
  • Escalation rule: any blocker unresolved for more than one working day goes to the project manager, and if it threatens a Must, to the sponsor.

AgilePM fit: this supports 'Collaborate' (communication adapted to the team's reality) and 'Demonstrate control' (visible tracking and escalation). It also respects the principle of tailoring - techniques should be adapted to context (distributed team, time zones) rather than applied rigidly. The test of the design is not 'is there a meeting?' but 'can a blocker be seen and acted on within a day?' If yes, the technical coordinator's concern is addressed.