ผมไม่แคร์ Scrum! (คำสารภาพจาก Barry Overeem): เมื่อ 'แก่น' สำคัญกว่า 'กระบวนท่า' 🤔📜❤️
“ทั้งหมดนี้มันเป็นส่วนหนึ่งของ Scrum Framework นั่นแหละ...แต่ในขณะเดียวกัน มันก็ไม่ใช่เรื่องของ Scrum เลยสักนิด” — Barry Overeem, (Co-founder The Liberators)
ในยุคที่ Agile ถูกพูดถึงทุกเวที ตั้งแต่ห้องประชุมบอร์ดบริหารไปจนถึงบูทแคมป์สายเทคโนโลยี เราเห็นองค์กรจำนวนมากพยายาม 'ทำให้ครบ' ตาม Scrum Guide ไม่ว่าจะเป็น Sprint Planning, Daily Scrum, Retrospective หรือ Role ต่างๆ อย่าง Product Owner, Scrum Master และ Developers
แต่คำถามคือ...ทำครบแล้วได้ผลจริงหรือไม่? หรือว่าเราแค่กำลัง “เช็กกล่องพิธีกรรม” โดยที่ไม่เข้าใจ “หัวใจ” ของ Agile เลย?
====
🧠 จุดเริ่มต้นของความคิดจาก Barry Overeem (Co-Founder The Liberators) ที่ฟังแล้วชวนสะดุ้ง!!!
Barry Overeem หนึ่งในผู้ร่วมก่อตั้ง The Liberators และผู้เชี่ยวชาญระดับสากลด้าน Scrum เคยเขียนบทความชื่อ "I Don’t Care About Scrum" พร้อมสารภาพตรงๆ ว่าเขา “ไม่ได้แคร์ว่าใครจะทำ Scrum หรือไม่!”
เขาบอกว่า เขาสนใจมากกว่าว่า…
1. ทีมเข้าใจ Empiricism หรือไม่? — ทีมสามารถทดลองสิ่งใหม่ เรียนรู้จากผลลัพธ์จริง และกล้าที่จะปรับเปลี่ยนวิธีทำงานอย่างรวดเร็วหรือเปล่า? การเข้าใจ Empiricism ไม่ใช่แค่การ “ลอง” แต่คือการ “เรียนรู้และปรับตัว” บนพื้นฐานของข้อมูลจริง ไม่ใช่ตามความรู้สึกหรือสมมติฐานลอยๆ
2. มี Trust ในทีมแค่ไหน? — ความไว้วางใจวัดได้จากการที่สมาชิกกล้าจะพูดถึงปัญหา กล้ารับผิด และกล้าส่งไม้ให้กันโดยไม่ต้องจับผิดซึ่งกันและกัน ทีมที่มี Trust จะกล้าเปิดเผยความเสี่ยง และมองปัญหาเป็นของร่วมกัน ไม่ใช่ของใครคนใดคนหนึ่ง
3. มี Psychological Safety หรือเปล่า? — สมาชิกในทีมรู้สึกปลอดภัยพอที่จะเสนอความคิดเห็นโดยไม่กลัวโดนตำหนิหรือดูถูกหรือไม่? กล้าท้าทายไอเดียของหัวหน้า? กล้ายอมรับว่าไม่รู้? ทีมที่มี Psychological Safety คือทีมที่ “กล้าเป็นมนุษย์” และเติบโตจากบทสนทนาจริง ไม่ใช่แค่การเออออตามกันไป
“ผมไม่ได้แคร์ว่าใครทำ Daily Standup หรือไม่... แต่ผมแคร์ว่าในทีมมีความเปิดใจ และกล้าพูดในสิ่งที่ควรพูดหรือเปล่า”
====
🔍 กับดักของ Scrum ที่หลายทีม (และหลายองค์กร) ติดอยู่โดยไม่รู้ตัว
* ยึดพิธีกรรมมากกว่าจุดประสงค์: Daily Scrum กลายเป็นเวทีรายงานแทนที่จะช่วยให้ทีมเห็นอุปสรรคร่วมกัน
* เชื่อว่าทำตาม Guide เป๊ะคือคำตอบสุดท้าย: ทั้งที่ความจริงแต่ละทีมมีบริบทที่แตกต่าง
* Retrospective ที่ไม่มีใครอยากพูดความจริง: ทำแบบขอไปที ไม่เคยนำไปปรับปรุงอะไรจริงจัง
* Sprint Review ที่เน้นโชว์สไลด์ มากกว่าโชว์ Feedback จริงจากผู้ใช้
* Scrum Master ที่กลายเป็น ‘ผู้จัดประชุม’ แทนที่จะเป็นผู้สร้างสภาพแวดล้อมแห่งการเรียนรู้
Barry ไม่ได้โจมตี Scrum แต่เขาชวนให้เราทบทวนว่า “คุณกำลังทำ Scrum หรือแค่ทำตามพิธีกรรม?”
====
❤️ สิ่งที่ควรให้ความสำคัญมากกว่า “การทำตาม Guide”
Barry ยก 11 แก่นสำคัญของ Agile ที่เขาแคร์มากกว่าการติดกรอบว่าใครคือ Scrum Master หรือ Daily ควรใช้กี่นาที เช่น
* Empiricism (ลงมือทำ เรียนรู้จากผลจริง) 🧪
ตัวอย่าง: ทีม Data Analyst ทดลองใช้โมเดล AI กับข้อมูลจริงโดยไม่รอคำสั่งจากหัวหน้า และนำผลลัพธ์มารีวิวร่วมกับทีมเพื่อปรับโมเดลทันทีภายในวันเดียว
* Transparency, Inspection, Adaptation (เปิดเผย ตรวจสอบ และปรับปรุง) 🔍
ตัวอย่าง: ทีม UX แชร์ Heatmap ของผู้ใช้จริงใน Miro Board ให้ทุกคนเห็นพร้อมกัน นำมาพูดคุยใน Weekly Review และเปลี่ยนดีไซน์ใหม่ทันที
* Self-organizing teams (ทีมที่บริหารตัวเองได้) 🚀
ตัวอย่าง: ทีม Developer สาย Startup วางตาราง Sprint เองทุก 2 สัปดาห์ โดยไม่ต้องรอ Project Manager กำหนดให้ เพราะเข้าใจเป้าหมายร่วมกัน
* Trust และ Psychological Safety (ความไว้วางใจ และความปลอดภัยทางจิตใจ) 🤝
ตัวอย่าง: สมาชิกใหม่เสนอเปลี่ยน Library หลักของระบบโดยไม่โดนตำหนิ แต่กลับได้รับการสนับสนุนให้ทำ PoC เพื่อตัดสินใจร่วมกัน
* Collaboration กับ Stakeholders อย่างแท้จริง (ร่วมมือกับผู้มีส่วนได้ส่วนเสีย) 🤲
ตัวอย่าง: ทีมออกแบบเชิญผู้ใช้จริงมาร่วม Co-Design Workshop เพื่อสร้าง Prototype ร่วมกัน โดยไม่รอ Feedback หลัง Dev เสร็จ
* Shared Ownership ของ Product (ความเป็นเจ้าของร่วมกันของทีม) 🏗️
ตัวอย่าง: Developer แสดงความเห็นในการเปลี่ยนแผน Product Roadmap เทียบเท่า Product Owner เพราะเชื่อว่าเขาคือคนที่จะสร้างสิ่งนั้นจริงๆ
* การตั้งเป้าหมายชัดในงานที่ซับซ้อน 🎯
ตัวอย่าง: ทีมที่ดูแล Platform Infrastructure วางเป้าหมายรายไตรมาสร่วมกับ Security Team เพื่อให้งาน DevOps, Reliability, และ Security ไปในทิศทางเดียวกัน
สิ่งเหล่านี้ทั้งหมด “มีอยู่ใน Scrum Framework” แต่ถ้าเรายึดแค่รูปแบบพิธีกรรม เราอาจพลาด “เนื้อใน” ไปอย่างน่าเสียดาย
แก่นแท้ที่ Barry แคร์คือความเข้าใจในหลักการ และความสามารถในการประยุกต์ใช้ตามบริบทจริง มากกว่าการทำตามตำราแบบไม่ลืมหูลืมตา
====
✅ Use Case “ทีมไหนที่เข้าใจแก่น มากกว่าท่องพิธีกรรม?”
* องค์กรสาย Fintech ที่ตัด Daily Standup แบบเดิม แล้วใช้ async standup ผ่าน Slack พร้อม Weekly Sync เพื่อถกอุปสรรคจริง เช่น ทีมพัฒนาแอปชำระเงินรายหนึ่ง เลือกสื่อสารผ่านข้อความใน Slack Channel โดยให้สมาชิกอัปเดตงานทุกเช้าก่อน 9 โมง และใช้เวลาทุกวันศุกร์ในการพูดคุยแบบเปิดกล้อง เพื่อสะท้อนอุปสรรคที่ต้องการความช่วยเหลือจริงๆ มากกว่าการรายงานงานที่ทำไปแล้ว
* ทีม R&D สายสุขภาพ ที่ไม่ทำ Sprint แต่แบ่งงานตาม Flow แบบ Kanban ใช้ Review กับคนไข้จริงเพื่อรับ Feedback เช่น กลุ่มนักวิจัยที่พัฒนาระบบติดตามอาการผู้ป่วยเบาหวาน ใช้การ์ด Kanban แทน Story Point และรีวิวผลการใช้งานกับกลุ่มผู้ป่วยนำร่องทุก 2 สัปดาห์ ทำให้สามารถปรับรูปแบบการแจ้งเตือนและ UX ของแอปให้เหมาะกับผู้สูงอายุได้เร็วขึ้น
* Start-up ไทย ที่ยกเลิก Role “Scrum Master” เพราะทีมสามารถจัดการตนเองได้ดี และให้นักออกแบบทำหน้าที่ Facilitator แทน เช่น บริษัทพัฒนาเกมมือถือที่เน้นความเร็วในการทดลองไอเดียใหม่ เลือกให้นักออกแบบเป็น Facilitator การประชุมทุกสัปดาห์แทน Scrum Master โดยเน้นการตั้งคำถามกระตุ้นเชิงกลยุทธ์ และช่วยเชื่อมโยงมุมมองของทีมศิลป์ ทีม Dev และทีมธุรกิจเข้าด้วยกัน
ทั้งหมดนี้ “ไม่ได้ทำ Scrum เป๊ะๆ” แต่กลับ “ได้ผลลัพธ์ที่ดีกว่า” เพราะเขาไม่ยึดติดกับพิธีกรรม แต่เกาะไว้ซึ่งเจตนา
====
🧭 เปรียบเทียบกับแนวคิดอื่น เพื่อเห็นว่า Agile คืออุดมการณ์ ไม่ใช่กรอบเดียว
* Lean Thinking: สนใจการไหลของคุณค่า (Value Stream) มากกว่า Timebox เช่น การออกแบบระบบการให้บริการผู้ป่วยที่โฟกัสการลดเวลารอรับยา โดยมองทั้ง Value Stream จากจุดรับบัตรจนถึงจ่ายยา ไม่ยึดติดว่าแต่ละขั้นตอนต้องใช้เวลากี่นาที แต่ดูว่าอะไรที่ทำให้ทั้งระบบลื่นไหลขึ้น
* Team Topologies: ชวนออกแบบทีมแบบ Platform Team, Enabling Team ซึ่งบางทีก็ไม่สอดคล้องกับ Role แบบ Scrum เช่น ในองค์กรเทคโนโลยีขนาดใหญ่ ทีมที่ดูแล DevOps หรือ Data Platform อาจไม่ได้เข้า Sprint ทุกครั้ง แต่กลับมีบทบาทสำคัญในการสนับสนุนทีม Product โดยตรง และทำให้ความเร็วทั้งองค์กรดีขึ้นมาก
* Flow-based Development: ลดพิธีกรรมที่ไม่สร้างคุณค่า ใช้ Flow Efficiency เป็นตัววัดสำคัญ เช่น ทีมที่เลือกไม่ใช้ Sprint แต่ใช้ Kanban ร่วมกับการวัด Lead Time, Cycle Time และ Blocker Rate แทน ซึ่งให้ภาพรวมของ Bottleneck ได้ตรงจุดกว่า และช่วยให้การปรับปรุงจริงจังเกิดขึ้นทุกวัน ไม่ต้องรอ Retrospective
ไม่ใช่การ “ทำตามตำรา” แต่คือการ “เอาหลักการมาออกแบบวิธีของตัวเอง” ที่เหมาะกับทีมและบริบท
====
💬 คำถามเชิงกลยุทธ์: คุณกำลังใช้ Scrum เพื่ออะไร?
1. คุณใช้ Scrum เพราะองค์กรสั่ง? หรือเพราะคุณเข้าใจเหตุผลของมันจริงๆ?
2. ทุก Event ที่คุณทำ มีจุดประสงค์ชัดเจน หรือทำเพราะ “ต้องทำให้ครบ”?
3. คนในทีมรู้สึกมีความหมายกับงาน? หรือแค่ทำไปเพราะกรอบบังคับ?
4. คุณมีการวัดคุณค่า (Value) ที่ทีมสร้างขึ้นจริงไหม? หรือแค่ปิด Story Point ให้ครบ?
====
🧠 ดังนั้น Framework ไม่ใช่จุดหมายปลายทาง แต่เป็นเข็มทิศให้เรากลับสู่ ‘สามัญสำนึก’ ของการทำงานร่วมกัน
“เครื่องมือที่ดีที่สุด ไม่ใช่เครื่องมือที่ฮิตที่สุด แต่คือเครื่องมือที่ช่วยให้เราเข้าใกล้เป้าหมาย และสะท้อนคุณค่าที่เรายึดถือออกมาได้อย่างแท้จริง”
ถ้าคุณเข้าใจ Agile จริง คุณอาจไม่ต้อง “ทำ Scrum ให้ครบทุกข้อ” ก็ได้
เพราะสุดท้าย...มันไม่ใช่เรื่องของ Scrum หรือไม่ Scrum
แต่มันคือเรื่องของ “ทีม”, “ความไว้วางใจ”, “การส่งมอบคุณค่า”, และ “การเติบโตไปด้วยกัน” ต่างหากครับ
(ที่มาแนวคิด : Barry Overeem , Co-founder The Liberators)
====
#วันละเรื่องสองเรื่อง
#AgileBeyondFramework
#ScrumWithPurpose
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2025 Blockdit
