Part 017 — Coordination, Blockers, Dependencies, and Remote Async Updates

Positioning

Daily Scrum bukan status meeting untuk manager.

Daily Scrum adalah event bagi Developers untuk:

• menginspeksi progress terhadap Sprint Goal;
• menyesuaikan Sprint Backlog;
• mengidentifikasi impediment;
• dan menyelaraskan kerja hari berikutnya.

Core thesis: Daily Scrum yang efektif menghasilkan keputusan koordinasi dan replanning, bukan hanya informasi.

1. Purpose of Daily Scrum

Daily Scrum menjawab:

Are we still on track toward the Sprint Goal?
What changed?
What needs to be adapted today?

Output yang diharapkan dapat berupa:

• perubahan sequencing;
• pairing;
• scope clarification;
• escalation;
• atau stop-start decision.

2. Daily Scrum versus Status Meeting

Daily Scrum

• audience utama: Developers;
• fokus: Sprint Goal dan plan;
• output: adaptation;
• ownership: team.

Status Meeting

• audience utama: manager/stakeholder;
• fokus: siapa mengerjakan apa;
• output: reporting;
• ownership: often external.

Smell

Jika setiap update diarahkan ke Scrum Master atau manager, event telah bergeser menjadi reporting.

3. Sprint Goal as the Anchor

Tanpa Sprint Goal, Daily Scrum menjadi round-robin.

Gunakan pertanyaan:

• item mana paling berkontribusi ke goal;
• risk apa yang mengancam goal;
• apakah optional scope harus dilepas;
• dan bantuan apa yang mempercepat goal.

4. Daily Scrum Formats

Scrum tidak mewajibkan tiga pertanyaan klasik.

Possible formats:

Goal-first walkthrough

Review progress menuju Sprint Goal.

Board walk

Mulai dari item paling dekat Done.

Blocked-first

Mulai dari blocked dan aging work.

Flow-first

Review WIP, queue, dan bottleneck.

Risk-first

Review assumptions dan dependencies.

Pilih format yang membantu adaptation.

5. Board Walk Technique

Mulai dari kanan ke kiri:

Done <- Validation <- Review <- In Progress <- Ready

Mengapa kanan ke kiri:

• finish before start;
• unblock work near completion;
• expose queues;
• reduce aging.

6. What to Inspect

• progress toward Sprint Goal;
• WIP;
• blocked items;
• aging work;
• review queue;
• test queue;
• dependency status;
• scope change;
• and production interruption.

7. Blocker versus Impediment

Blocker

Menghentikan work item tertentu.

Impediment

Mengurangi effectiveness team atau sistem.

Contoh:

• missing access = blocker;
• recurring access process = impediment.

Daily Scrum dapat menemukan keduanya, tetapi systemic impediment memerlukan follow-up di luar event.

8. Blocker Model

Blocker:
Affected item:
Impact on Sprint Goal:
Owner:
Next action:
Expected resolution:
Escalation trigger:

Blocker tanpa owner adalah hanya observation.

9. Dependency Coordination

Daily Scrum harus memeriksa critical dependency.

Questions:

• status berubah;
• evidence tersedia;
• owner merespons;
• fallback perlu diaktifkan;
• atau escalation threshold tercapai.

10. Replanning

Replanning dapat mencakup:

• pairing;
• reassigning work;
• changing order;
• splitting scope;
• removing optional item;
• adding validation;
• or escalating dependency.

Sprint Backlog adalah plan yang hidup.

11. Scope Change during Sprint

Scope dapat diklarifikasi dan dinegosiasikan.

Questions:

Does the change support the Sprint Goal?
What is the capacity impact?
What should be removed?
Does quality remain intact?
Who owns the decision?

Avoid silent scope growth.

12. Daily Scrum and WIP

Daily Scrum should challenge:

• too many started items;
• review queue;
• QA queue;
• and idle blocked work.

Key question:

What can we finish today before starting something new?

13. Aging Work

Aging item is work that has remained active too long.

Daily Scrum should inspect:

• age;
• reason;
• remaining work;
• uncertainty;
• and intervention.

Aging is often a better risk signal than percent complete.

14. Handoffs

Handoff queues may occur between:

• developer and reviewer;
• engineering and QA;
• team and platform;
• team and security;
• or provider and consumer.

Daily Scrum should expose queue time.

15. Pairing and Swarming

If critical item is blocked or aging:

• pair;
• swarm;
• bring specialist;
• or re-slice.

Team effectiveness matters more than individual utilization.

16. Problem Solving during Daily Scrum

Daily Scrum should identify and coordinate.

Deep problem-solving may move to a follow-up with relevant people.

Avoid making everyone stay for unrelated technical detail.

17. Timebox

Daily Scrum is timeboxed to 15 minutes.

The goal is not speed reporting.

The goal is focused inspection and adaptation.

If event regularly exceeds time:

• board unclear;
• too much WIP;
• problem-solving mixed in;
• or team too large.

18. Async Daily Updates

Async updates may help remote teams.

Suggested format:

Sprint Goal status:
Completed evidence:
Current focus:
Blocker/risk:
Decision/help needed:

Async update should not replace coordination when real-time discussion is needed.

19. Sync plus Async Hybrid

Example:

• written update before overlap;
• short sync for blockers and decisions;
• follow-up huddle for technical issue;
• board updated continuously.

This avoids repetitive reporting.

20. Remote Time Zone Challenges

Risks:

• delayed blocker response;
• handoff latency;
• context loss;
• and no shared overlap.

Mitigations:

• explicit response SLA;
• decision log;
• clear handoff note;
• ownership;
• and contingency.

21. Daily Scrum and Production Incident

If incident occurs:

• assess severity;
• activate incident process;
• inspect Sprint Goal impact;
• renegotiate scope;
• and communicate.

Do not pretend Sprint plan is unchanged.

22. Daily Scrum and Stakeholders

Stakeholders may observe if useful, but Daily Scrum belongs to Developers.

Stakeholder questions should not hijack adaptation.

Use separate update channels for broader reporting.

23. Scrum Master Role

Scrum Master helps ensure event effectiveness.

Not required to lead or attend every time.

Healthy progression:

• team can conduct useful Daily Scrum independently.

24. Product Owner Role

Product Owner may participate if needed, especially for scope clarification.

But should not turn event into acceptance or priority assignment.

25. Engineering Manager Role

Manager should avoid using Daily Scrum for individual status.

Manager can help remove structural impediments outside the event.

26. Senior Engineer Role

Senior engineer should:

• focus on flow;
• identify hidden risk;
• offer pairing;
• reduce technical ambiguity;
• and avoid monopolizing discussion.

Anti-bottleneck behavior

• ask who can own next step;
• share context;
• delegate decisions;
• and avoid taking every hard problem.

27. Daily Scrum Anti-Patterns

Three-question theater

Everyone reports, no plan changes.

Manager-facing updates

Team speaks upward.

Ticket-by-ticket narration

No goal focus.

Problem-solving marathon

Timebox lost.

Blocker without action

Same blocker repeated.

No board accuracy

Conversation and artifact diverge.

Async wall of text

No one reads or responds.

Senior monologue

One person dominates.

28. Failure Modes

Sprint Goal risk found too late

Daily inspection weak.

Many items almost done

WIP too high.

Blocker repeated for days

No escalation.

QA queue grows

Handoff not managed.

Remote dependency stalls

No response policy.

29. Worked Example: Approval Flow Sprint

Sprint Goal

Pilot tenant can complete approval flow.

Daily state

• UI complete;
• API in review;
• audit event blocked by schema decision;
• QA environment ready.

Useful Daily Scrum outcome

• senior pairs on schema decision;
• API reviewer prioritizes review;
• UI developer helps contract test;
• optional dashboard item deferred;
• dependency escalated if no decision by noon.

This is adaptation, not reporting.

30. Daily Scrum Facilitation Template

1. Sprint Goal status.
2. Work nearest Done.
3. Blocked and aging work.
4. Review/test queues.
5. Dependency changes.
6. Replanning decisions.
7. Follow-up huddles.

31. Process Smells

• Daily Scrum never changes plan;
• same blocker repeated;
• board updated before event only;
• all items in progress;
• manager asks each person;
• no one mentions Sprint Goal;
• remote updates lack decisions;
• and follow-up ownership unclear.

32. Internal Verification Checklist

Format

• What Daily Scrum format is used?
• Is board walked right-to-left?
• Is Sprint Goal discussed?
• Who facilitates?

Blockers

• How are blockers marked?
• Who owns escalation?
• What threshold is used?
• Are systemic impediments tracked separately?

Remote

• Is async update used?
• What overlap hours exist?
• What response expectation exists?
• How are handoffs documented?

Flow

• Are WIP and aging visible?
• Are review/QA queues discussed?
• Is pairing/swarming common?
• Does the plan change based on evidence?

Roles

• Does manager attend?
• Does Product Owner attend?
• Is the event reporting-oriented?
• Can Developers run it independently?

33. Practical Exercises

Exercise 1 — Rewrite the Daily

Design a 15-minute format around Sprint Goal and flow.

Exercise 2 — Blocker ownership

Take one recurring blocker and document owner, next action, and escalation.

Exercise 3 — Aging review

Identify active items older than team norm.

Exercise 4 — Async template

Create concise async update format.

Exercise 5 — Replanning simulation

Assume one dependency slips three days. Replan Sprint while preserving goal.

34. Part Completion Checklist

You are done if you can:

• explain Daily Scrum as inspection and adaptation;
• distinguish it from status reporting;
• use Sprint Goal as anchor;
• manage blockers and dependencies;
• inspect WIP and aging;
• combine sync and async coordination;
• and contribute as senior engineer without dominating.

35. Key Takeaways

1. Daily Scrum is for Developers.
2. The output is adaptation.
3. Sprint Goal is the anchor.
4. Board walk should favor finishing.
5. Blockers need owner and escalation.
6. WIP and aging are critical signals.
7. Remote updates need decision context.
8. Deep problem-solving can move to follow-up.
9. Senior engineers should improve flow.
10. Internal Daily Scrum practice must be verified.

36. References

Conceptual baseline:

• The Scrum Guide.
• General Agile flow, coordination, and remote-team practices.

These concepts do not describe internal CSG processes.