สกรัมเป็น Empirical process

กระบวนการแก้ปัญหาในโลกแบ่งเป็น 2 แบบ แบบแรกคือ Defined process ซึ่งเป็นกระบวนการที่มีขั้นมีตอนชัดเจน เช่น Waterfall เป็นต้น ส่วนแบบที่สองคือ Empirical process หรือ "กระบวนการเชิงประจักษ์" ซึ่งเป็นการทำไปแล้วก็ปรับไปเรื่อย ๆ สกรัมเป็นแบบหลัง

ปกติกระบวนการสองแบบนี้เหมาะจะใช้แก้ปัญหาในบริบทที่แตกต่างกัน และเราก็มักจะเลือกใช้มันอย่างเหมาะสมได้อย่างเป็นธรรมชาติอยู่แล้ว เช่น เวลาเราขับรถกลับบ้านจากที่ทำงานที่เรากลับเป็นประจำ ปกติก็จะเช็ค Google Maps แค่ครั้งเดียวเพื่อเลือกเส้นทางที่ "ประหยัด" ที่สุด หรือบางคนอาจจะไม่ดูแมพเลยด้วยซ้ำ เพราะทางกลับบ้านฉันมีทางเดียวนี่แหละ

ในทางกลับกัน สมมติวันนี้เรามีนัดเลี้ยงรุ่น แล้วร้านที่เพื่อนนัดดันเป็นร้านที่เราไม่รู้จักเลย ต่อให้ระยะทางเท่ากัน แต่วิธีการเช็ค Google Maps เราจะไม่เหมือนเดิม บางคนอาจจะเช็คทุก 10 นาที บางคนอาจจะเช็คทุก 5 นาที หรือบางคนอาจจะเช็คทุกแยก เอาเป็นว่ายิ่งกลัวหลง ก็ยิ่งเช็คบ่อย

ทุกครั้งที่เราหยิบแมพมาดู จะเกิด 1 ใน 2 อย่างขึ้น คือ:

1. ประจักษ์แล้วว่าเราเข้าใจถูกต้อง ก็แล้วก็แล้วกันไป
2. ประจักษ์แล้วว่าเราเข้าใจผิด แล้วก็ต้องปรับ

กระบวนการแก้ปัญหาแบบ Empirical นี้ที่จริงก็ไม่มีอะไรมาก ถ้าพูดง่ายๆ ก็คือ:

1. Inspect: สังเกต
2. Adapt: ปรับ

Scrum guide พูดว่า Scrum ใช้ empirical process control theory หรือ empiricism เป็น foundation หลัก สกรัมเลยจำเป็นต้องมีสิ่งที่ทำให้ empiricism ทำงานได้ดี นั้นก็คือ:

1. Transparency: ทุกคนที่เกี่ยวข้องมองเห็นสิ่งที่กำลังเกิดขึ้น ณ ปัจจุบัน ได้ตรงกัน
2. Inspection: ทุกคนที่เกี่ยวข้องตรวจสอบ artifacts ที่กำลังทำและความคืบหน้าสู่ goal อยู่บ่อยๆ
3. Adaptation: เมื่อพบว่า artifacts หรือกระบวนการมีปัญหา ก็ปรับโดยเร็ว

ในทางปฏิบัติ เพื่อทำให้เกิด Transparency, Inspection, และ Adaptation สกรัมจึงสร้าง events และ artifacts ต่างๆขึ้นมา เช่น Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Product Backlog, Sprint Backlog, Increment

โดยเฉพาะ Sprint Review นั้นเป็น event ที่ออกแบบมาเพื่อ Inspect & Adapt โดยตรง นักสกรัมมาสเตอร์ควรทำให้แน่ใจว่า Sprint Review นั้นมีประสิทธิภาพ เต็มไปด้วยการ Inspect และ Adapt ไม่ใช่แค่เป็นเพียง demo หรือ show & tellกระบวนการแก้ปัญหาในโลกแบ่งเป็น 2 แบบ แบบแรกคือ Defined process ซึ่งเป็นกระบวนการที่มีขั้นมีตอนชัดเจน เช่น Waterfall เป็นต้น ส่วนแบบที่สองคือ Empirical process หรือ "กระบวนการเชิงประจักษ์" ซึ่งเป็นการทำไปแล้วก็ปรับไปเรื่อย ๆ สกรัมเป็นแบบหลัง

ปกติกระบวนการสองแบบนี้เหมาะจะใช้แก้ปัญหาในบริบทที่แตกต่างกัน และเราก็มักจะเลือกใช้มันอย่างเหมาะสมได้อย่างเป็นธรรมชาติอยู่แล้ว เช่น เวลาเราขับรถกลับบ้านจากที่ทำงานที่เรากลับเป็นประจำ ปกติก็จะเช็ค Google Maps แค่ครั้งเดียวเพื่อเลือกเส้นทางที่ “ประหยัด” ที่สุด หรือบางคนอาจจะไม่ดูแมพเลยด้วยซ้ำ เพราะทางกลับบ้านฉันมีทางเดียวนี่แหละ

ในทางกลับกัน สมมติวันนี้เรามีนัดเลี้ยงรุ่น แล้วร้านที่เพื่อนนัดดันเป็นร้านที่เราไม่รู้จักเลย ต่อให้ระยะทางเท่ากัน แต่วิธีการเช็ค Google Maps เราจะไม่เหมือนเดิม บางคนอาจจะเช็คทุก 10 นาที บางคนอาจจะเช็คทุก 5 นาที หรือบางคนอาจจะเช็คทุกแยก เอาเป็นว่ายิ่งกลัวหลง ก็ยิ่งเช็คบ่อย

ทุกครั้งที่เราหยิบแมพมาดู จะเกิด 1 ใน 2 อย่างขึ้น คือ:

1. ประจักษ์แล้วว่าเราเข้าใกล้เป้าหมายมากขึ้น เลยได้ความมั่นใจที่จะไปต่อ
2. ประจักษ์แล้วว่ามาผิดทาง แล้วได้ข้อมูลเพื่อจูงใจให้เราเปลี่ยนทิศทางในการเดินทาง

นี่แหละครับคือกระบวนการเชิงประจักษ์ ซึ่งในกระบวนการแบบนี้เราไม่ถามหาความ “ประหยัด” แต่เราเฝ้าถามตลอดว่า “เราเข้าใกล้เป้าหมายมากขึ้นไหม” ทุก ๆ รอบที่เราขับไปเราได้ระยะทาง แต่ไม่เสมอไปที่ระยะทางนั้นจะทำให้เราเข้าใกล้เป้าหมายมากขึ้น

และสิ่งที่เราเกลียดที่สุดคือการหยิบแมพขึ้นมาแล้วเจอว่า GPS ไม่อัปเดต เพราะเราไม่รู้ว่าเราเข้าใกล้เป้าหมายมากขึ้นไหม เราเลยต้องวัดดวงขับทางเดิมเพิ่มอีกรอบ แล้วก็ค่อยพบว่าเลยแยกไปแล้วจนต้องกลับรถ

เปรียบเทียบกับสกรัม

ทุก ๆ รอบการทำงาน ทีมจะใช้เงินและแรงในการสร้าง Output (ระยะทาง) แต่ไม่เสมอไปที่เราจะเข้าใกล้เป้าหมายมากขึ้น (Outcome) สกรัมเลยมีกิจกรรมที่ชื่อว่า Sprint Review เพื่อให้ทีมเอา Output ที่สร้างมาตรวจสอบว่ามันทำให้ได้ Outcome ที่เราอยากได้ไหม

ความถี่ในการตรวจสอบ ก็คือระยะเวลาของ Sprint ถ้าเรายิ่งอยู่ในสถานการณ์ที่เสี่ยงจะหลงทาง ก็ยิ่งอยากเช็คบ่อย ๆ เวลาพลาดจะได้ไม่ต้องกลับตัวไกล แต่ถ้ามั่นใจก็สามารถมี Sprint ที่ยาวขึ้นได้

และถ้าไม่มีความเสี่ยงที่จะหลงเลย เราก็กลับไปใช้ Defined process อย่าง Waterfall คือวางแผนรอบเดียวแล้วมุ่งหาความคุ้มค่าและความประหยัด แทนที่จะคอยขับไปเช็คไป

Sprint review มีไว้เพื่อการเรียนรู้

สาเหตุที่สกรัมอยากให้สร้าง Cross-functional team เพราะโครงสร้างของทีมจะสัมพันธ์มากกับปริมาณการเรียนรู้ที่เกิดขึ้นใน Sprint Review เช่น ถ้าในทีมมีทักษะครบตั้งแต่ Business Analysis, UX/UI Design, Frontend Development, Backend Development ไปจนถึง Infrastructure Engineering ทีมก็จะใช้เวลาใน Sprint Review ได้อย่างคุ้มค่ามาก เช่น นั่งดูผล A/B Testing ที่ทำใน Sprint ที่ผ่านมาว่าสมมติฐานไหนทำให้ได้ผลลัพธ์ดีกว่ากัน

แต่ถ้าเปรียบเทียบกับโครงสร้างของอีกทีมที่ยังแบ่งคนทำ Frontend กับ Backend ออกจากกัน Review ของทีม Frontend ก็จะเหลือแค่เช็คว่าของที่ทำมาถูกใจ Product Owner ไหม ซึ่งบางครั้งก็ต่อกับ Mock Data บางครั้งก็ต่อ API จริง ขึ้นอยู่กับว่าทีมไหนทำเสร็จก่อน ทั้งหมดนี้จะ Work บนสมมติฐานว่า Product Owner รู้ดีว่า User อยากได้อะไร ซึ่งสมมติฐานนี้จะถูก Validate อีกทีเมื่อซอฟต์แวร์ถึงมือ User จริง ๆ เท่านั้น

ส่วนทีมหลังบ้าน บ่อยครั้งก็จะมี Tech Lead มานั่งตรวจ API หรือ Audit Log ด้วยสมมติฐานว่าสิ่งที่ทำมาจะเอาไป Integrate กับหน้าบ้านได้โดยไม่ต้องแก้ไขอะไร ซึ่งถ้าไม่จริงก็ต้องกลับมา Rework กันใหม่

สำหรับผม เวลานั่งดู Sprint Review ของทีมที่มีทักษะไม่ครบ ชวนให้ผมนึกถึงจังหวะหยิบมือถือมาเช็ค Map แล้วเจอว่า GPS ไม่อัปเดตเลย คือเงินที่เราลงไปอีก 1 Sprint นี้ ไม่ทำให้ผมรู้เลยว่าเราเข้าใกล้เป้าหมายมากขึ้นหรือน้อยลง ได้แค่รู้ว่าของที่ออกมาตรงใจใครบางคนไหมเฉย ๆ ซึ่งบ่อยครั้งพอไปถึงมือ User จริง ๆ ก็ต้องเปลี่ยนอีก

ที่ผมเอาเรื่องนี้มาแบ่งปันเพราะในยุคนี้ที่ AI ช่วยสร้างและแก้ของได้อย่างรวดเร็วมาก ๆ แล้ว ปัญหาที่เราเคยมีว่าการแก้ของกลับไปกลับมามันวุ่นวาย เลยต้องแยกทีมกันนั่งเพื่อความเสถียร มันน่าจะหายไปแล้วหรือเปล่า? ในยุคที่อยากเพิ่มสักหนึ่งฟิลด์ (Field) ใน API แล้วให้ AI ทำให้ 5 นาทีก็เสร็จ มันจะดีกว่าไหมถ้าเราจะเอาทุกคนที่เกี่ยวข้องในการสร้างผลลัพธ์ (Outcome) มานั่งใกล้ ๆ กัน จะได้แก้ของไปพร้อม ๆ กันได้เลย

ถ้าเราต้องเจอกับ GPS ไม่อัปเดตทุก Sprint เราจะขับรถไปเช็ค Map ไปให้หงุดหงิดใจทำไมนะ สู้ขับรวดเดียวแล้วไปวัดดวงปลายทางเลยดีกว่าไหม? การทำ Waterfall แล้วกำหนด Release สั้น ๆ อาจจะเหมาะกับคุณมากกว่าการทำสกรัมก็ได้นะ