🛑 หยุดเรียกตัวเองว่า Agile ถ้าองค์กรคุณยังคิดแบบ Waterfall
🛑 หยุดเรียกตัวเองว่า Agile ถ้าองค์กรคุณยังคิดแบบ Waterfall
เมื่อ Agile กลายเป็น “พิธีกรรม” มากกว่า “วิธีคิด”
ในช่วง 10 ปีที่ผ่านมา คำว่า “Agile” กลายเป็นคำที่องค์กรแทบทุกแห่งอยากมีติดตัว ไม่ต่างจากคำว่า Digital Transformation หรือ AI-first
หากเดินเข้าไปถามผู้บริหารในองค์กรขนาดใหญ่ คำตอบที่ได้แทบจะเหมือนกันทั้งหมด
“เราทำ Agile แล้วครับ มี Scrum มี Sprint มี Daily ครบ”
แต่เมื่อมองลึกลงไปในระดับการทำงานจริง สิ่งที่ปรากฏกลับเป็นภาพที่แตกต่างอย่างสิ้นเชิง เช่น
* ทีมมี Sprint ทุก 2 สัปดาห์ แต่ Requirement ถูกกำหนดล่วงหน้าแบบล็อกตาย 6–12 เดือน
* ทีมถูกบอกให้ “iterate” แต่ทุกการเปลี่ยนแปลงต้องผ่าน approval หลายชั้น
* ทีม deploy ได้เร็วขึ้น แต่ release สู่ลูกค้าต้องรอรอบใหญ่ตาม cycle เดิม เป็นต้น
"สิ่งนี้ไม่ใช่ Agile"
แต่มันคือสิ่งที่วงการเรียกว่า “Water-Scrum-Fall” หรือการเอาพิธีกรรมของ Agile มาครอบโครงสร้างการคิดแบบ Waterfall และนั่นคือจุดที่หลายองค์กรกำลัง “หลอกตัวเอง” โดยไม่รู้ตัว
====
"Waterfall ไม่ใช่ผู้ร้าย” แต่มันถูกใช้ผิดบริบท
"หนึ่งในความเข้าใจผิดที่อันตรายที่สุดคือ การมองว่า Waterfall เป็นสิ่งล้าหลัง"
ความจริงคือ Waterfall ถูกออกแบบมา เพื่อโลกที่ “ความไม่แน่นอนต่ำ” และ “ต้นทุนของความผิดพลาดสูง” กล่าวคือ งานที่สามารถนิยามขอบเขตได้ชัด มีข้อกำกับด้านความปลอดภัย/กฎระเบียบ และไม่ยอมรับการทดลองผิดพลาดได้ง่าย เช่น
* ระบบการเงินหลัก (Core Banking) ที่ต้องรักษาความถูกต้องของธุรกรรมระดับสูง
* ระบบควบคุมเครื่องมือแพทย์ ที่ความผิดพลาดอาจกระทบชีวิตผู้ป่วย
* โครงสร้างพื้นฐานขนาดใหญ่ เช่น ระบบสาธารณูปโภค หรือโครงการวิศวกรรม
ในบริบทเหล่านี้ การวางแผนล่วงหน้าอย่างละเอียด การทบทวนแบบเป็นลำดับขั้น และการทดสอบก่อนใช้งานจริง ไม่ใช่ “ความเชื่องช้า” แต่คือกลไกควบคุมความเสี่ยงที่จำเป็น เพราะความผิดพลาดหนึ่งครั้งอาจมีต้นทุนมหาศาล ทั้งในเชิงการเงิน ชื่อเสียง และความปลอดภัย
อีกมุมหนึ่ง Waterfall ยังช่วยให้การบริหารทรัพยากร การประมาณงบประมา ณ และการกำหนด timeline ทำได้แม่นยำขึ้นในสภาพแวดล้อมที่ตัวแปรไม่ผันผวนมาก ซึ่งเป็นสิ่งที่องค์กรขนาดใหญ่จำนวนมากต้องการ
Waterfall จึงไม่ใช่ระบบที่แย่ แต่มันคือระบบที่เหมาะกับโลกที่ “รู้คำตอบตั้งแต่ต้น” และต้อง “คุมความเสี่ยงให้แน่น”
====
Agile ของแท้ ไม่ได้เริ่มที่ Sprint แต่เริ่มที่ “ความไม่รู้”
Agile ไม่ได้ถูกสร้างมาเพื่อทำงานให้เร็วขึ้น แต่มันถูกสร้างมาเพื่อรับมือกับโลกที่ “เราไม่รู้คำตอบล่วงหน้า”
โดยเฉพาะในผลิตภัณฑ์ดิจิทัล ที่ความต้องการของลูกค้าเปลี่ยนเร็ว การแข่งขันสูง และพฤติกรรมผู้ใช้ไม่เสถียร สิ่งที่ทีมคิดว่า “ใช่” วันนี้ อาจกลายเป็น “ไม่ตอบโจทย์” ในอีกไม่กี่สัปดาห์ข้างหน้า
หัวใจของ Agile จึงไม่ใช่ความเร็วเชิงปฏิบัติการ (execution speed) แต่คือความเร็วในการ “เรี ยนรู้” (learning speed) ซึ่งถูกสะท้อนผ่านแนวคิดจาก Agile Manifesto
"Responding to change over following a plan"
นั่นหมายความว่า
* แผนสามารถเปลี่ยนได้ หากข้อมูลใหม่ชี้ว่าทิศทางเดิมไม่ถูกต้อง
* Requirement ไม่จำเป็นต้องถูกต้องตั้งแต่วันแรก เพราะมันคือ “สมมติฐาน” ไม่ใช่ “ข้อเท็จจริง”
* และทีมต้องเรียนรู้จาก “ของจริง” ในตลาด เช่น usage, behavior, conversion ไม่ใช่แค่ “ความคิดเห็น” ในห้องประชุม
ตัวอย่างที่เห็นได้จริงคือ ทีมที่ปล่อย feature ขนาดเล็กไปทดสอบกับผู้ใช้กลุ่มย่อย แล้วใช้ data ตัดสินใจว่าจะ scale ต่อหรือหยุด ต่างจากทีมที่ใช้เวลา 6 เดือนสร้างของให้ “สมบูรณ์” แต่ไม่มีใครใช้
* ดังนั้น Agile ที่แท้จริงคือระบบที่ออกแบบมาเพื่อลด “cost of being wrong” ผ่านการทดลองขนาดเล็กและ feedback ที่รวดเร็ว
* องค์กรที่ยังต้องการให้ทุกอย่าง “สมบูรณ์ 100% ก่อนปล่อย” หรือพยายาม eliminate ความเสี่ยงทั้งหมดตั้งแต่ต้น
* กำลังทำสิ่งตรงข้ามกับ Agile โดยสิ้นเชิง และมักจะแลกมาด้วย cycle ที่ยาวขึ้น ต้นทุนที่สูงขึ้น และการเรียนรู้ที่ช้าลง
====
ปัญหาจริงไม่ใช่ Framework แต่คือ “ระบบอำนาจ” ในองค์กร
สิ่งที่ทำให้ Agile ล้มเหลวในองค์กรขนาดใหญ่ ไม่ใช่เพราะทีมไม่เข้าใจ Scrum แต่เป็นเพราะ “ระบบอำนาจและการตัดสินใจ” ยังถูกออกแบบมาเพื่อโลกแบบ Waterfall กล่าวคือ อำนาจรวมศูนย์ การอนุมัติหลายชั้น และการหลีกเลี่ยงความเสี่ยงเป็นหลัก
โครงสร้างเช่นนี้มักสะท้อนผ่าน 3 เรื่องหลัก
* การตัดสินใจแบบรวมศูนย์: ทีมไม่มี mandate ที่แท้จริงในการตัดสินใจเชิงผลิตภัณฑ์ ต้องรอผู้บริหารหรือคณะกรรมการ ทำให้ decision latency สูง และสูญเสียจังหวะของการเรียนรู้จากตลาด
* การวัดผลแบบ output แทน outcome: องค์กรให้รางวัลกับ “ทำเสร็จตาม แผน” มากกว่า “สร้างผลลัพธ์ให้ธุรกิจ” ส่งผลให้ทีม optimize ที่ความเร็วในการส่งมอบ feature แทนที่จะ optimize ที่คุณค่า (value) ที่ลูกค้าได้รับ
* การบริหารความเสี่ยงแบบ “ต้องไม่พลาดเลย”: ทุกการเปลี่ยนแปลงถูกมองเป็นความเสี่ยงที่ต้องควบคุม ไม่ใช่โอกาสในการเรียนรู้ ทำให้วงจรทดลอง (experiment) ถูกจำกัดและช้าลง
เมื่อองค์กรยังต้องการความแน่นอน 100% แต่บอกทีมให้ทำ Agile สิ่งที่เกิดขึ้นจริงคือ “Agile ถูกลดรูปให้เป็นเพียงพิธี sกรรม” ขณะที่แกนการตัดสินใจยังคงเดิม
* ผลลัพธ์คือทีมจะกลายเป็นเพียง execution layer ที่ทำตามคำสั่งใน Sprint ไม่มีอำนาจในการตั้งสมมติฐาน ทดลอง หรือ pivot ตามข้อมูลจริง และสุดท้าย Sprint ก็เป็นเพียงการแบ่งช่วงของ Waterfall ให้สั้นลง
* ซึ่งในเชิงระบบ นี่ไม่ใช่ Agile ที่ล้มเหลว แต่คือ “โครงสร้างองค์กรที่ไม่เคยถูกออกแบบมาเพื่อ Agile ตั้งแต่ต้น”
====
Product Manager = จากคนเขียน Requirement สู่คนตัดสินใจเชิงธุรกิจ
ในระบบที่ทำงานจริง บทบาทของ Product Manager คือ “จุดตัดของธุรกิจ เทคโนโลยี และลูกค้า” ซึ่งเป็นตำแหน่งที่กำหนดทิศทางว่าองค์กรจะสร้างอะไร? และสร้างไปเพื่ออะไร?
แนวคิดจากหนังสือ The Product Book อธิบายบทบาทของ PM ไว้ชัดเจนว่า PM ไม่ใช่คนเขียน requirement แต่คือคนที่ต้องเข้าใจว่า “อะไรคือสิ่งที่ควรสร้าง?” และ “ทำไมต้องสร้าง?” โดยอาศัยทั้งข้อมูล (data) และวิจารณญาณ (judgment)
ในโลก Waterfall
* PM คือ Architect ที่ต้องออกแบบทุกอย่างให้ชัดตั้งแต่ต้น
* ต้องทำ Upfront Discovery ให้ครบ ทั้ง stakeholder, use case, constraint
* และลดความเสี่ยงด้วยการกำหนดขอบเขตที่แน่น เพื่อให้ execution เป็นไปตามแผน
ในโลก Agile
* PM คือ Navigator ที่ต้องตัดสินใจภายใต้ข้อมูลที่ไม่สมบูรณ์
* ต้องเรียนรู้จาก data จริงอย่างต่อเนื่อง เช่น usage, retention, feedback
* และกล้าปรับทิศทาง (pivot) เมื่อสิ่งที่คิดไว้ไม่สอดคล้องกับพฤติกรรมผู้ใช้
สิ่งที่เปลี่ยนไปอย่างมีนัยสำคัญคือ PM ในโลกปัจจุบันต้อง “ตัดสินใจเร็วขึ้น แต่ไม่ใช่ตัดสินใจแบบเดา” กล่าวคือ ใช้การทดลองขนาดเล็กและ feedback loop เพื่อเพิ่มคุณภาพของการตัดสินใจในแต่ละรอบ
ปัญหาคือหลายองค์กรยังคาดหวังให้ PM ทำทั้งสองอย่างพร้อมกัน คือ
“วางแผนให้แม่นตั้งแต่ต้น และต้องยืดหยุ่นเมื่อโลกเปลี่ยน”
ซึ่งในเชิงระบบแทบเป็นไปไม่ได้ เพราะการ optimize เพื่อความแน่นอน (certainty) และการ optimize เพื่อการเรียนรู้ (learning) ต้องใช้วิธีคิดและโครงสร้างที่ต่างกันโดยสิ้นเชิง
ผลลัพธ์ที่มักเกิดขึ้นคือ PM ถูกลดบทบาทเหลือเพียง “คนกลาง” ที่รวบรวม requirement จากหลายฝ่าย โดยไม่มีอำนาจตัดสินใจจริง ขณะที่ทีมก็สูญเสียทิศ ทางเชิงผลิตภัณฑ์ และนี่คือเหตุผลว่าทำไมการยกระดับ PM ไม่ใช่เรื่องของตำแหน่ง แต่คือเรื่องของ “อำนาจในการตัดสินใจบนข้อมูลจริง”
====
อะไรคือสัญญาณว่าองค์กรคุณกำลังเป็น “Water-Scrum-Fall”?
องค์กรจำนวนมากไม่ได้ตั้งใจจะทำ Water-Scrum-Fall แต่ค่อยๆ กลายเป็นโดยไม่รู้ตัวผ่านการประนีประนอมระหว่าง “ความอยาก Agile” กับ “ความกลัวความเสี่ยง”
สัญญาณที่ 1 "มี Sprint แต่ไม่มีการเปลี่ยนแปลงจริง"
* ทีมทำงานเป็น Sprint อย่างเคร่งครัด แต่สิ่งที่ต้องทำในแต่ละ Sprint ถูกกำหนดไว้ล่วงหน้าแบบตายตัวจาก roadmap ระยะยาว
* นั่นหมายความว่า Sprint ไม่ได้เป็นเครื่องมือของการเรียนรู้ แต่เป็นเพียง “กรอบเวลาในการส่งงานตามแผน”
สัญญาณที่ 2 "ทีมพูดว่า Agile แต่ทุกอย่างต้องขออนุมัติ"
* การเปลี่ยนแปลงเล็กๆ เช่น UI ปุ่มเดียว ต้องผ่าน approval หลายระดับ
* สิ่งนี้สะท้อนว่าอำนาจการตัดสินใจยังอยู่ที่ส่วนกลาง ไม่ได้อยู่ที่ทีม
* Agile จึงกลายเป็นเพียง execution framework ไม่ใช่ decision framework
สัญญาณที่ 3 "Deploy ได้ แต่ release ไม่ได้"
* ทีมสามารถ build และ deploy ได้เร็วขึ้น แต่ไม่สามารถปล่อยให้ลูกค้าใช้จริงได้ เพราะต้องรอ QA, compliance หรือ release window แบบรวมศูนย์
* ผลลัพธ์คือ feedback loop ยังช้าเหมือนเดิม
สัญญาณที่ 4 "วัดผลด้วย output ไม่ใช่ outcome"
* องค์กรยังให้ความสำคัญกับ "จำนวน feature ที่ส่งมอบ” และ "ความตรงตาม timeline” มากกว่าผลลัพธ์ทางธุรกิจ เช่น adoption, revenue หรือ customer impact
* ทีมจึงโฟกัสที่ “ทำให้เสร็จ” มากกว่า “ทำให้ได้ผล”
สัญญาณที่ 5 "Product Manager ไม่มีอำนาจจริง"
* แม้จะมีตำแหน่ง Product Owner หรือ Product Manager แต่การตัดสินใจสำคัญยังอยู่กับผู้บร ิหารหรือ stakeholder หลายฝ่าย
* PM จึงกลายเป็นเพียง coordinator ของ requirement แทนที่จะเป็นคนตัดสินใจเชิงผลิตภัณฑ์
"ถ้าองค์กรคุณมีมากกว่า 3 ใน 5 ข้อ = คุณไม่ได้ทำ Agile หรอก"
====
"Water-Scrum-Fall" ต้นทุนที่องค์กรไม่เคยมองเห็น
องค์กรจำนวนมากคิดว่าการเปลี่ยนมาใช้ Agile จะช่วยให้เร็วขึ้น แต่ในความเป็นจริง Water-Scrum-Fall มักสร้าง “ต้นทุนแฝง” ที่สูงกว่าเดิม เพราะองค์กรไม่ได้เปลี่ยนแค่ framework แต่เพิ่ม “layer ของความซ้ำซ้อน” เข้าไปบนระบบเดิม
ต้นทุนเหล่านี้ไม่ได้อยู่ในงบประมาณโดยตรง แต่สะท้อนผ่าน productivity ที่ลดลง ความล่าช้าในการตัดสินใจ และคุณภาพของการเรียนรู้ที่ด้อยลง
* ทีมต้องทำเอกสารแบบ Waterfall + ทำพิธีกรรม Agile เพิ่ม → งานเพิ่ม แต่คุณค่าไม่ได้เพิ่มตาม
* Decision latency สูงขึ้น เพราะยังต้องผ่าน governance เดิม → ก ารตัดสินใจช้าลง แม้ทีมจะทำงานเป็น Sprint
* Feedback loop ช้า เพราะยัง deploy ไม่ได้จริง → ทีมไม่ได้เรียนรู้จากผู้ใช้ แต่เรียนรู้จาก “สมมติฐานเดิม” ซ้ำไปซ้ำมา
* Context switching สูงขึ้น เพราะทีมต้องตอบสนองทั้ง roadmap ระยะยาวและ Sprint ระยะสั้นพร้อมกัน → ทำให้ focus ลดลงและประสิทธิภาพการทำงานตก
ผลลัพธ์ที่เกิดขึ้นจริงในหลายองค์กรคือ ทีมรู้สึก “ยุ่งขึ้น” แต่ไม่ได้ “ดีขึ้น” กล่าวคือใช้เวลามากขึ้นในการประสานงาน ประชุม และทำ alignment แทนที่จะใช้เวลาไปกับการสร้างคุณค่าให้ลูกค้า
“ทีมทำงานหนักขึ้น แต่ธุรกิจไม่ได้เร็วขึ้น”
ในเชิงเศรษฐศาสตร์องค์กร นี่คือรูปแบบของ organizational drag หรือแรงเสียดทานภายในที่ทำให้ระบบเคลื่อนที่ช้าลง แม้จะมีความพยายามเพิ่มความเร็วในระดับทีมก็ตาม และสิ่งที่น่ากังวลที่สุดคือ ต้นทุนประเภทนี้มักไม่ถูกวัด ไม่ถูก report และไม่ถูกแก้ไข เพราะมันซ่อนอยู่ใน “วิธีการทำงาน” ไม่ใช่ในงบประมาณ
====
บทเรียนสำหรับผู้บริหาร คือ อย่าเลือก Framework แต่ให้เลือก “ความจริง” ของธุรกิจ
คำถามที่สำคัญไม่ใช่ “องค์กรเราควรเป็น Agile หรือ Waterfall?” แต่คือ “งานแบบนี้ต้องการความแน่นอนหรือความเร็วในการเรียนรู้มากกว่ากัน” เพราะสองสิ่งนี้มัก trade-off กันโดยธรรมชาติ
ดังนั้นก่อนเลือกวิธีทำงาน ผู้บริหารควรถามให้ชัดว่า
* งานนี้มีความไม่แน่นอนแค่ไหน? เป็น problem ที่รู้คำตอบแล้ว หรือยังเป็น hypothesis ที่ต้องทดลองกับตลาด
* ต้นทุนของความผิดพลาดสูงหรือไม่? ถ้าพลาดแล้วกระทบเงิน/ความปลอดภัย/กฎระเบียบสูง อาจต้องเพิ่มความเข้มงวดแบบ Waterfall แต่ถ้าพลาดแล้วเรียนรู้ได้เร็ว Agile จะได้เปรียบ
* ทีมมีอำนาจตัดสินใจจริงหรือเปล่า? ถ้าไม่มี mandate ให้ทีมตัดสินใจ Agile จะเหลือแค่พิธีกรรมโดยอัตโนมัติ
อีกมุมที่มักถูกมองข้ามคือ “ต้นทุนของการรอคอย” (cost of delay) หากการอนุมัติช้า 2–4 สัปดาห์ในตลาดที่เปลี่ยนทุกไตรมาส นั่นอาจมีต้นทุนสูงกว่าความผิดพลาดจากการทดลองขนาดเล็กเสียอีก
เพราะสุดท้ายแล้ว ลูกค้าไม่เคยสนใจว่าองค์กรคุณใช้ Scrum หรือ Waterfall ลูกค้าสนใจแค่ว่า
“คุณแก้ปัญหาให้เขาได้หรือไม่ และเร็วพอหรือไม่เมื่อเทียบกับทางเลือกอื่นในตลาด”
====
สัญญาณเตือนใหม่?
“เมื่อ AI กำลังจะ disrupt ทั้ง Agile, Scrum และ Waterfall"
สิ่งที่หลายองค์กรยังมองไม่เห็นคือ การถกเถียงว่า Agile หรือ Waterfall ดีกว่า อาจกำลังกลายเป็นคำถามที่ “ล้าสมัย” ลงอย่างรวดเร็ว
เพราะ AI ไม่ได้เข้ามาเปลี่ยนแค่เครื่องมือ แต่กำลังเปลี่ยน “ธรรมชาติของการทำงาน” ทั้งระบบ
* งานจำนวนมากที่เคยต้องใช้คน เช่น การเขียน requirement, การทำ documentation, การวิเคราะห์ data หรือแม้แต่การ generate solution เบื้องต้น กำลังถูก AI เข้ามาช่วยทำได้ในระดับที่เร็วกว่าและถูกกว่าอย่างมีนัยสำคัญ
* บทบาทอย่าง Product Manager, Business Analyst หรือแม้แต่ Developer กำลังถูก redefine จาก “คนที่สร้าง” ไปสู่ “คนที่ตัดสินใจว่าจะสร้างอะไร”
* Framework อย่าง Scrum หรือ Waterfall ซึ่งถูกออกแบบมาในยุคที่ “ความเร็วของมนุษย์คือข้อจำกัดหลัก” กำลังถูกท้าทาย เมื่อ AI ทำให้ cycle ของการทดลองและการพัฒนาสั้นลงอย่างก้าวกระโดด
นั่นหมายความว่าองค์กรที่ยังติดอยู่กับการ optimize “process เดิม” อาจกำลังพลาดโอกาสในการ redesign วิธีการทำงานทั้งระบบ
* งานส่วนไหนควรให้ AI ทำแทน?
* การตัดสินใจแบบไหนยังต้องใช้มนุษย์?
* และองค์กรจะ redesign workflow อย่างไรเมื่อ cost ของ experimentation ใกล้ศูนย์?
ดังนั้น “Framework เดิมอาจไม่ใช่คำตอบอีกต่อไป”
====
ดังนั้น Agile ไม่ใช่สิ่งที่ “ทำ” แต่คือสิ่งที่ “ยอมรับ”
องค์กรจำนวนมากพยายาม “ทำ Agile” แต่ไม่เคย “ยอมรับความไม่แน่นอน” ซึ่งเป็นหัวใจของ Agile จริงๆ การมี Daily Stand-up ไม่ได้ทำให้องค์กรคุณเป็น Agile แต่การกล้ายอมรับว่า “เราอาจคิดผิด และเราพร้อมจะเปลี่ยน” ต่างหากที่ทำให้ Agile มีความหมาย เพราะในโลกธุรกิจ ความเร็วไม่ได้มาจากการประชุมบ่อยขึ้น แต่มาจากการตัดสินใจได้เร็วขึ้นบนข้อมูลจริง และนั่นคือสิ่งที่องค์กรจำนวนมากยังไปไม่ถึง
องค์กรที่ยังถกเถียง "Agile vs Waterfall" ในปีนี้ อาจกำลังแก้ปัญหาของปีที่แล้ว ในขณะที่การแข่งขันของปีหน้ากำลังถูกกำหนดโดย AI และวิธีทำงานแบบใหม่ที่ยังไม่มีชื่อเรียกด้วยซ้ำ
====
📚 Source / Reference
* Beck, K. et al. (2001). Manifesto for Agile Software Development — https://agilemanifesto.org/
* Añón, C. & Product School (2017). The Product Book: How to Become a Great Product Manager. Product School.
* Forrester Research. Water-Scrum-Fall concept (industry analysis on hybrid development models)
