Sprint Disrupting Request

Background

• Gw kerja di perusahaan startup yang apa-apa harus cepat
• Prosedur masih berantakan dan dokumentasi masih minim

Pre-condition

• Banyak stakeholder yang bisa ngide tiba dan submit ide tersebut tengah sprint
• Seringkali langsung ke engineer dan nggak kasih tahu vital stakeholder lainnya, including PM
• Nggak ada waktu untuk validasi ide tersebut
• Expected untuk ide itu bisa segera dieksekusi tanpa nunggu next sprint

Problem

• Communication problem
• Akan ada stakeholder yang nggak ke inform dan bingung dengan hasil delivery yang "lain" daripada yang awalnya mereka ketahui dan sepakati
• Stakeholder deny permintaan mereka sendiri, dan tidak ada bukti karena semua nya verbal
• Delivery problem
• Delivery timeline aka ter-disrupt dan bisa terjadi delay
• Long term risk
• Trust diantara stakeholder akan semakin menipis
• Escalated to blaming game

Solution discovery

• Masalah dibahas di sprint retro
• Di confirm oleh product and tech team
• Solusi dirumuskan dan disetujui untuk dijalankan oleh semua tim product and tech

Action plan

• Dokumentasi request dan change request menjadi tanggung jawab tim product
• Pengambilan keputusan apakah request dan change request akan dijalankan harus dibicarakan dengan team product
• Recorded confirmation harus ada
• Channel untuk meminta konfirmasi hanya lewat email
• A simple OK reply on email sudah cukup
• Jika stakeholder insists, confirmation bisa lewat whatsapp -> Di screenshot dan di attach di email oleh product team - CC semua stakeholder agar semua mengetahui
• Recorded confirmation harus mudah diakses ketika terjadi dispute
• Attached on email
• Print to PDF dan attached to JIRA and Confluence
• Dalam kasus emergency, developer BOLEH develop change request, tetapi hanya boleh di submit / push setelah dokumentasi change request di sign off

Result

• Nggak ada yang berani deny request lagi
• Trust between team meningkat