ทำไม Agile ในไทยถึงพัง: วิธีแก้กับดัก 2-Week Waterfall และมีตติ้งที่สูญเปล่า

ยอมรับมาเถอะ... บริษัทของคุณประกาศรับ การทำงานแบบ Agile เข้ามาเมื่อ 2 ปีที่แล้ว ผู้บริหารซื้อ Post-it มาแปะเต็มบอร์ด จัดออฟฟิศใหม่แบบ Open Space และจู่ๆ ทุกคนก็เริ่มพูดคำว่า "สปรินต์" หรือ "สแตนด์อัพ" แต่ในความเป็นจริง มีอะไรเปลี่ยนไปบ้างไหมในแง่ของผลลัพธ์? หรือคุณแค่มีประชุมโผล่เข้ามาในปฏิทินเพิ่มขึ้นอีกสัปดาห์ละ 5 นัด?

สารบัญ / Table of Contents

• Table of Contents
• The Brutal Truth About Agile in Thailand
  • ปัจจัยความ "เกรงใจ" ในห้อง Retrospective
  • เมื่อ Project Manager สวมบทเป็น Scrum Master ข้ามคืน
  • Product Owner ที่ไม่มีอำนาจตัดสินใจจริง
• The Meeting-ification Problem
• Fixing Your Agile Transformation Failure
  • 1. เลิกยึดติดกับ "สปรินต์ 2 สัปดาห์" ที่เป็นพิษ
  • 2. ปรับใช้ Kanban ที่เหมาะกับทีมไทยมากกว่า
  • 3. เน้นการสื่อสารแบบ Async และวัดผลที่ผลลัพธ์ (Outcome)
• How iRead Adapts Agile for Thai Business Culture
• Conclusion
• FAQ
  • ถ้าไม่ใช้ สปรินต์ 2 สัปดาห์ แล้วจะรู้ได้อย่างไรว่างานจะเสร็จเมื่อไหร่?
  • หัวหน้างานไม่ยอมลดมีตติ้ง เพราะกลัวทีมงานไม่อัปเดต ควรทำอย่างไร?
  • จะเริ่มเปลี่ยนจาก Scrum ที่พังๆ มาเป็น Kanban ได้อย่างไร?

ความจริงที่หลายคนไม่อยากยอมรับก็คือ Agile ในไทย มักจะห่างไกลจากภาพฝันในซิลิคอนแวลลีย์มาก เรานำเอา Framework ของเขามาสวมทับโครงสร้างแบบเดิมๆ โดยไม่ปรับเปลี่ยน Mindset ทำให้สุดท้ายมันกลายเป็นความเจ็บปวดของทั้งทีม Dev และฝั่ง Business วันนี้เราจะมาคุยกันแบบตรงไปตรงมา ไม่โลกสวย ว่าทำไมมันถึงพัง และทีมของคุณควรจะเปลี่ยนไปใช้วิธีไหนแทน

Table of Contents

• The Brutal Truth About Agile in Thailand
• The Meeting-ification Problem
• Fixing Your Agile Transformation Failure
• How iRead Adapts Agile for Thai Business Culture
• Conclusion
• FAQ

The Brutal Truth About Agile in Thailand

เหตุผลหลักที่ Agile มักจะล้มเหลวไม่เป็นท่าในประเทศไทย ไม่ใช่เพราะเราใช้เครื่องมืออย่าง Jira หรือ Trello ไม่เก่ง แต่เป็นเพราะเรากำลังเอา Framework ที่ออกแบบมาเพื่อโครงสร้างองค์กรแบบแบนราบ (Flat Hierarchy) มายัดใส่ใน วัฒนธรรมองค์กรไทย ที่มีลำดับขั้น (Hierarchical Culture) อย่างเหนียวแน่น

ปัจจัยความ "เกรงใจ" ในห้อง Retrospective

Agile ขับเคลื่อนด้วย Feedback Loop ที่รวดเร็วและตรงไปตรงมา ถ้ามีปัญหา ทุกคนต้องกล้าพูดใน Sprint Retrospective แต่ในไทย สิ่งที่เกิดขึ้นคือความ "เกรงใจ" จูเนียร์ไม่กล้าบอกว่าที่งานล่าช้าเพราะ "พี่ซีเนียร์ส่งบรีฟช้า" หรือ "ไดเรกเตอร์เปลี่ยน Requirement กะทันหัน" เมื่อไม่มีใครพูดความจริง ปัญหาที่แท้จริงก็ไม่เคยถูกแก้ เราขอแนะนำให้คุณลองศึกษาเรื่อง psychological safety in Thai workplaces เพื่อทำความเข้าใจปัญหานี้ให้ลึกขึ้น

เมื่อ Project Manager สวมบทเป็น Scrum Master ข้ามคืน

หลายบริษัทแก้ปัญหาโครงสร้างองค์กรด้วยการแค่ "เปลี่ยนชื่อตำแหน่ง" Project Manager (PM) คนเดิมที่คุ้นเคยกับการคุมคนด้วย Gantt Chart และ Timeline แบบเป๊ะๆ ถูกจับมาเปลี่ยนชื่อเป็น Scrum Master ผลลัพธ์คือ? เขายังคงทวงงานแบบเดิม สั่งงานแบบ Top-down เหมือนเดิม แค่เปลี่ยนจากคำว่า "งานนี้เสร็จวันไหน" เป็น "Task นี้ Story Point เท่าไหร่ แล้วจะย้ายไป Done ได้กี่โมง"

Product Owner ที่ไม่มีอำนาจตัดสินใจจริง

ปัญหาคลาสสิกอีกอย่างคือตำแหน่ง Product Owner (PO) ตามหลักการแล้ว PO ต้องมีอำนาจชี้ขาดว่าอะไรควรทำก่อน-หลัง แต่ในบริบทของไทย PO มักจะเป็นแค่คนรับสาร (Messenger) ที่ต้องเอา Backlog ไปรอให้ระดับ C-Level อนุมัติอีกที ทำให้คอขวดไม่ได้หายไปไหน แค่ย้ายที่อยู่เท่านั้น

The Meeting-ification Problem

คำว่า Agile มักถูกนำมาใช้เป็นข้ออ้างในการเพิ่มตารางประชุม ลองดูตัวอย่างที่เจ็บปวดที่สุด: Daily Standup Meeting

ตามทฤษฎี มันคือการประชุม 15 นาทีที่ทุกคนยืนคุยกันสั้นๆ ว่าเมื่อวานทำอะไร วันนี้จะทำอะไร และติดปัญหาอะไรไหม แต่ในความเป็นจริงของ Agile ในไทย สิ่งนี้กลายร่างเป็น "รายงานสถานะการทำงาน 45 นาที" เพราะหัวหน้าทีมหรือผู้บริหารเข้ามานั่งฟังด้วย พนักงานเลยรู้สึกว่าต้องอธิบายยืดยาวเพื่อพิสูจน์ว่าตัวเองกำลังทำงานหนักอยู่ ไม่ได้อู้งาน การประชุมที่ควรจะช่วยแก้ปัญหา กลับกลายเป็นสิ่งที่สูบพลังงานทีมตั้งแต่ 9 โมงเช้า

หรือแม้แต่กระบวนการทำ สปรินต์ (Sprint) 2 สัปดาห์ แทนที่จะได้ซอฟต์แวร์ที่พร้อมใช้งานทีละส่วน มันกลับกลายเป็น "Mini-Waterfall" หรือ Waterfall จำแลง กล่าวคือ:

• วันที่ 1-3: ฝั่ง Business เพิ่งเริ่มส่ง Requirement
• วันที่ 4-11: Dev เร่งปั่นโค้ดแบบไฟลนก้น
• วันที่ 12-13: โยนงานทั้งหมดให้ QA เทสต์ (ซึ่งหาบั๊กเจอเพียบ แต่แก้ไม่ทันแล้ว)
• วันที่ 14: ปล่อยงานที่มีบั๊กขึ้น Production ไปก่อนเพื่อรักษา KPI ของสปรินต์

Fixing Your Agile Transformation Failure

หากอ่านมาถึงตรงนี้แล้วคุณรู้สึกว่า "นี่มันบริษัทเราชัดๆ" อย่าเพิ่งหมดหวัง คุณไม่จำเป็นต้องโละทุกอย่างทิ้งแล้วกลับไปใช้ Waterfall เต็มรูปแบบ คุณแค่ต้องปรับให้เข้ากับจริตของคนทำงาน

1. เลิกยึดติดกับ "สปรินต์ 2 สัปดาห์" ที่เป็นพิษ

ถ้าสปรินต์ของคุณจบลงด้วยความตายของทีม QA ทุกๆ วันศุกร์เว้นศุกร์ ให้เลิกบังคับใช้ Timebox ที่ตายตัว การบังคับให้งานทุกชิ้นต้องเสร็จภายใน 2 สัปดาห์มักจะทำให้คุณภาพงานลดลง เปลี่ยนโฟกัสจากการ "ทำให้เสร็จตามรอบ" เป็นการ "ทำให้เสร็จทีละชิ้นอย่างมีคุณภาพ"

2. ปรับใช้ Kanban ที่เหมาะกับทีมไทยมากกว่า

นี่คือทางออกที่หลายบริษัทในไทยใช้แล้วเวิร์กสุดๆ การ ปรับใช้ Kanban ตอบโจทย์องค์กรที่ Requirement เปลี่ยนบ่อยและมีงานด่วนแทรกเสมอ

• จำกัด Work In Progress (WIP): แทนที่จะยัดงาน 20 ชิ้นให้เสร็จใน 2 สัปดาห์ บังคับเลยว่าทีม Dev แต่ละคนถือ Task ในมือได้ไม่เกิน 2 งาน จนกว่าจะเทสต์ผ่านและ Deploy ค่อยหยิบงานใหม่ วิธีนี้ช่วยลดความเครียดและหลีกเลี่ยงบริบทการสลับงาน (Context Switching) ที่กินสมอง
• Flow over Timebox: ปล่อยให้งานไหลไปตามท่อ (Pipeline) เรื่อยๆ ไม่ต้องรอปิดรอบสปรินต์เพื่อปล่อยฟีเจอร์ใหม่

3. เน้นการสื่อสารแบบ Async และวัดผลที่ผลลัพธ์ (Outcome)

ลดมีตติ้งลงครึ่งหนึ่ง สแตนด์อัพมีตติ้งสามารถทำผ่าน Slack หรือ Microsoft Teams ได้ ไม่จำเป็นต้องลากทุกคนมาเปิดกล้อง effective remote team communication ให้พนักงานอัปเดตสถานะแบบ Asynchronous (ไม่ต้องตอบโต้ทันที) แล้ววัดผลการทำงานที่ "งานสำเร็จตามเป้าหมายไหม" ไม่ใช่ "นั่งทำงานครบ 8 ชั่วโมงหรือเปล่า"

How iRead Adapts Agile for Thai Business Culture

ที่ iRead เราผ่านจุดนั้นมาหมดแล้ว เราทำงานร่วมกับลูกค้าฝั่ง B2B และ Enterprise ในไทยมามากมาย เราเรียนรู้ว่าการบังคับลูกค้าและทีมให้ทำ Agile แบบ Silicon Valley 100% นั้นไม่เวิร์ก

สิ่งที่เราทำคือการสร้าง Practical Agile:

1. Kanban-First Approach: เราบริหารงานโปรเจกต์ลูกค้าด้วยบอร์ด Kanban ที่เห็นชัดเจนว่าคอขวดอยู่ตรงไหน โดยเฉพาะคอขวดที่เกิดจาก "รอการอนุมัติจากผู้ใหญ่" (ซึ่งเป็นเรื่องปกติในไทย) ทีม Dev ของเราจะไม่หยุดรอ แต่จะดึง Task ถัดไปที่พร้อมทำขึ้นมาทันที
2. Flexible Scope, Firm Boundaries: เรารับมือกับ Culture ที่ชอบเปลี่ยน Requirement ด้วยการกำหนด Scope ที่ยืดหยุ่นได้ แต่มีขอบเขตชัดเจน ถ้าแทรกงานด่วน งานอื่นต้องถูกเด้งออกไป ไม่มีการบอกว่า "ฝากทำให้หน่อยนะน้อง"
3. Data-Driven Standups: เราใช้ระบบบอทในแชทเพื่อเก็บสเตตัสรายวันของทีม ทำให้เวลาประชุม 15 นาทีของเราเอาไว้คุยเฉพาะปัญหาที่ต้องช่วยกันแก้จริงๆ (Blockers) ไม่ใช่มานั่งเล่านิทานว่าเมื่อวานทำอะไรไปบ้าง

Conclusion

การนำ Agile มาใช้นั้นเป็นเรื่องดี แต่วิธีที่เรานำมาใช้นั้นต่างหากที่เป็นปัญหา การบังคับใช้กระบวนการที่เน้นความเร็วและความเท่าเทียมในสภาพแวดล้อมที่เต็มไปด้วยความเกรงใจและลำดับขั้น ย่อมนำไปสู่ความล้มเหลว ทางรอดของ Agile ในไทย ไม่ใช่การทำตามตำราให้เป๊ะขึ้น แต่คือการประยุกต์ใช้เครื่องมืออย่าง Kanban และการเคารพธรรมชาติของ วัฒนธรรมองค์กรไทย อย่างเข้าใจ เมื่อคุณเลิกยึดติดกับพิธีกรรม (Ceremonies) และหันมาสนใจคุณค่าที่แท้จริง (Values) ของงาน เมื่อนั้นทีมของคุณถึงจะกลับมาเร็วและคล่องตัวได้อย่างแท้จริง

FAQ

ถ้าไม่ใช้ สปรินต์ 2 สัปดาห์ แล้วจะรู้ได้อย่างไรว่างานจะเสร็จเมื่อไหร่?

คุณสามารถใช้ข้อมูล Lead Time จากกระดาน Kanban เพื่อประเมินเวลาแทนได้ การทำงานแบบ Kanban จะให้สถิติเฉลี่ยว่างานแต่ละชิ้นใช้เวลาตั้งแต่เริ่มจนจบกี่วัน ซึ่งมักจะแม่นยำกว่าการให้ Dev กะเวลาในตอนเริ่มสปรินต์

หัวหน้างานไม่ยอมลดมีตติ้ง เพราะกลัวทีมงานไม่อัปเดต ควรทำอย่างไร?

ลองเสนอการทำ "Async Update" ผ่านแชทหรือระบบแจ้งเตือนแบบอัตโนมัติเป็นเวลา 2 สัปดาห์เพื่อพิสูจน์ให้เห็นว่าความโปร่งใส (Transparency) ของงานไม่ได้ลดลง แถมหัวหน้ายังมีเวลาไปโฟกัสกับงานเชิงกลยุทธ์มากขึ้น

จะเริ่มเปลี่ยนจาก Scrum ที่พังๆ มาเป็น Kanban ได้อย่างไร?

เริ่มต้นง่ายๆ ด้วยการเลิกกำหนดเวลาของสปรินต์ ค่อยๆ เริ่มใช้บอร์ดเดิมที่มีอยู่ แต่เพิ่มกฎการจำกัด Work in Progress (WIP Limits) ให้แต่ละสเตตัสเพื่อแก้ปัญหาคอขวดก่อนทีละจุด