“AI is killing the Scrum we got used to”
ช่วงนี้ผมเริ่มรู้สึกว่า “AI กำลังฆ่า Scrum แบบที่หลายองค์กรคุ้นชิน” ไปแล้วครับ 😅
ไม่ได้หมายความว่า Scrum หมดความจำเป็น แต่กิจวัตรหลายอย่าง เช่น การประชุมวางแผนยาวๆ การแตกงานละเอียด การประเมินขนาดงาน หรือการรอรอบ Sprint ก่อนลองของจริง กำลังถูก AI ท้าทาย
คำถามสำคัญจึงไม่ใช่ “เรายังต้องใช้ Scrum หรือไม่” แต่คือ
ส่วนไหนของกระบวนการยังช่วยให้ทีมเรียนรู้และส่งมอบคุณค่าได้จริง และส่วนไหนควรปรับให้เหมาะกับบริบทใหม่
1. AI เปลี่ยนต้นทุนการทำงาน?
เมื่อก่อนกว่าจะเก็บ Requirement, Design, เขียน Code, Test และได้ของจริงให้ User ลอง ต้องใช้เวลามาก
ดังนั้นการคุย วางแผน แตกงาน และจัดลำดับก่อนลงมือทำจึงมีเหตุผล เพราะ “Execution แพง”
แต่วันนี้บางทีมอาจประชุมกันเป็นชั่วโมง ขณะที่ AI Agent สร้าง Prototype, Code และ Test ชุดแรกออกมาให้ลองได้แล้ว 😅
ของนั้นอาจยังไม่พร้อม Production และยังต้อง Review, ตรวจ Security, ดู Architecture รวมถึงมีคนรับผิดชอบผลลัพธ์
แต่สิ่งที่เปลี่ยนชัดคือ
ต้นทุนของการ “ลองทำ” กำลังลดลงเร็วกว่าต้นทุนของการ “เตรียมก่อนทำ”
อย่างไรก็ตาม ไม่ได้หมายความว่าทุกงานควรลด Process ลงทั้งหมด งานที่มีความเสี่ยงสูง มีข้อกำกับด้านความปลอดภัย มี Dependency ซับซ้อน หรือ Product ยังไม่แน่นอน ยังคงต้องอาศัยการวางแผน ตรวจสอบ และทำงานเป็นรอบ
2. สิ่งที่ควรทบทวน?
“Estimation และ Story Point”
Story Point ไม่ใช่สิ่งที่ Scrum บังคับใช้ แต่หลายองค์กรใช้คู่กับ Scrum จนกลายเป็นภาพจำ
มันเคยช่วยประเมินขนาดหรือ Effort ของงานได้ดีในโลกที่คนเป็นผู้ลงมือทำเกือบทั้งหมด
แต่เมื่อ Agent เข้ามาช่วย งานที่มนุษย์มองว่าต่างกันมากในแง่ Effort อาจไม่ได้ต่างกันในสัดส่วนเดิม
คำถามจึงไม่ใช่แค่ “กี่ Point?” แต่คือ
“เรายังจำเป็นต้องบริหารงานด้วยหน่วยวัดแบบเดิมหรือเปล่า?”
Estimation ยังมีประโยชน์สำหรับคุยเรื่องความเสี่ยง วาง Capacity ประสานงาน และตัดสินใจว่าจะทดลองอะไรต่อ แต่ไม่ควรใช้เป็นเป้าหมายหรือวัดคุณค่าของทีมแบบตายตัว
“การแตกงาน”
การแตกงานเป็นชิ้นเล็กช่วยให้คนเข้าใจและติดตามง่ายขึ้น แต่ AI ก็ต้องการ Context เช่นกัน
บางครั้งการให้ภาพรวมของ Business Intent, Constraint, Architecture และเหตุผล อาจทำให้ Agent ทำงานได้ดีกว่าการโยน Ticket เล็กๆ ที่ถูกตัดออกจากเรื่องใหญ่
ถ้าแตกละเอียดเกินไป สิ่งที่เคยช่วยคนอาจทำให้ Agent เข้าใจบริบทน้อยลง
อย่างไรก็ตาม งานที่มีความเสี่ยงสูง ต้อง Review หลายขั้นตอน หรือต้องแบ่งความรับผิดชอบชัดเจน ก็ยังควรแตกงานเพื่อควบคุมคุณภาพ
สิ่งสำคัญจึงไม่ใช่ “แตกงานหรือไม่แตก” แต่คือเลือกความละเอียดให้เหมาะกับคน ระบบ และ Agent
“Scrum Events และ Process”
Scrum Events อย่าง Sprint Planning, Daily Scrum, Sprint Review หรือ Retrospective ยังมีคุณค่า หากช่วยให้ทีม Inspect, Adapt, ตัดสินใจ และเรียนรู้เร็วขึ้น
แต่สิ่งที่ควรหายไปคือ การทำ Event หรือ Practice เพียงเพราะเคยทำแบบนั้นมา
โดยเฉพาะเมื่อเวลาประชุมใกล้เคียงหรือมากกว่าเวลาที่ใช้ทดลองของจริง
ประเด็นจึงไม่ใช่การลด Process ให้เหลือน้อยที่สุด แต่คือ
การมี Process เท่าที่จำเป็นต่อคุณภาพ การเรียนรู้ และความรับผิดชอบร่วมกัน
“Velocity และการวัดผลงาน”
Velocity ไม่ใช่ข้อบังคับของ Scrum แต่หลายองค์กรใช้เป็นตัวแทนความเร็วของทีมมานาน
ในโลกที่ AI ทำให้ Output เพิ่มขึ้นง่าย สิ่งที่ขาดแคลนอาจไม่ใช่กำลังในการสร้าง แต่เป็น Judgment ว่าอะไรควรถูกสร้าง
รวมถึง Context, Quality และความเข้าใจว่าสิ่งที่สร้างขึ้นมาแก้ปัญหาจริง หรือแค่เพิ่ม Output ให้ดูเยอะขึ้น
Velocity อาจใช้ดูแนวโน้มภายในทีมได้ แต่ไม่ควรใช้เป็นเป้าหมาย เปรียบเทียบทีม หรือสรุปว่าทีมที่สร้าง Output มากกว่ามีประสิทธิภาพกว่าเสมอไป
3. บทบาทใหม่ของคน?
จากเดิมที่ใช้พลังกับการ Estimate, Track และ Coordinate งาน ต่อไปคุณค่าของคนอาจอยู่ที่
* การกำหนดโจทย์
* การให้ Context
* การมองภาพรวม
* การตัดสินใจเรื่อง Trade-off
* การตรวจคุณภาพ
* การจัดการความเสี่ยง
* ความรับผิดชอบต่อ Outcome
AI จะช่วยทำ How ได้มากขึ้นเรื่อยๆ
ส่วนคนต้องเก่งขึ้นกับ What, Why และ Judgment
ความรับผิดชอบจึงย้ายจากการควบคุมทุกขั้นตอน ไปสู่การกำหนดโจทย์ ตรวจสอบคุณภาพ และตัดสินใจในเรื่องที่ยังต้องใช้บริบทและวิจารณญาณ
4. แนวทางปรับใช้ Scrum
“Scrum ที่ถูกทำจนกลายเป็นพิธีกรรมจะอยู่ยากขึ้นเรื่อยๆ”
แต่ไม่ได้หมายความว่าต้องทิ้งทุกอย่าง
* Sprint ยังอยู่ได้ ถ้าช่วยให้เรียนรู้เร็วขึ้น
* Planning ยังอยู่ได้ ถ้าช่วยลดความเสี่ยงจริง
* Review ยังอยู่ได้ ถ้าช่วยให้ Feedback ดีขึ้น
* Retrospective ยังอยู่ได้ ถ้าทำให้ทีมดีขึ้นจริง
แนวทางสำคัญคือ
* ใช้เมื่อมันช่วย
* ปรับเมื่อบริบทเปลี่ยน
* เลิกเมื่อมันไม่สร้างคุณค่า
* รักษาไว้เมื่อช่วยให้ทีมรับมือกับความไม่แน่นอนได้ดีขึ้น
ทุกกระบวนการควรตอบให้ได้ว่า
“มันช่วยให้เราส่งมอบคุณค่าได้ดีขึ้นจริง หรือแค่ทำเพราะเราทำแบบนี้มานานแล้ว”
เมื่อ Execution เร็วขึ้นหลายเท่า Process ที่เคยช่วยให้ทีมไปเร็วขึ้นก็อาจกลายเป็นสิ่งที่ทำให้ทีมช้าลง
ขณะเดียวกัน การลด Process โดยไม่เข้าใจเหตุผลก็อาจทำให้คุณภาพลดลงและความเสี่ยงเพิ่มขึ้น
5. บทสรุป
AI กำลังบังคับให้เราเลือกใช้แต่ละส่วนอย่างมีเหตุผลมากขึ้น สิ่งที่สำคัญไม่ใช่การทำตาม Framework ให้ครบทุกขั้นตอน แต่คือการสร้างระบบการทำงานที่ช่วยให้ทีม
* เรียนรู้เร็วขึ้น
* ตัดสินใจดีขึ้น
* ควบคุมความเสี่ยงได้
* รักษาคุณภาพ
* และส่งมอบ Outcome ที่มีคุณค่า
ผมชอบเปรียบเทียบง่ายๆ แบบนี้ครับ
“เราอาจกำลังมีเครื่องยนต์ Formula 1 อยู่ในมือ แต่ไม่ควรให้รถจอดทุก 100 เมตรเพียงเพื่อประทับตราว่าทำ Process ครบแล้ว และก็ไม่ควรถอดเบรกออกเพียงเพราะรถวิ่งเร็วขึ้น” 😅
#วันละเรื่องสองเรื่อง
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2026 Blockdit
