เป็นหนังสือที่อ่านเพลินๆ มี Anti-Patterns แบบต่างๆ ตั้งแต่คำว่า Scrum, Roles, Artifacts, Events มีความเจ็บปวดที่เคยเจอ ซึ่งในส่วน Article นี้ขอเป็นแค่ คำว่า Scrum ก่อน

หลายองค์กรกระโดดเข้าสู่การใช้ Scrum ด้วยความหวังว่ามันจะเป็นยาวิเศษที่ช่วยให้ทีมทำงานได้เร็วขึ้นและสร้างผลิตภัณฑ์ที่ดีขึ้น แต่ไม่นานก็พบว่าผลลัพธ์ไม่เป็นไปตามที่คาดหวัง ทีมเริ่มรู้สึกเหมือนกำลัง “ทำตามขั้นตอน” ที่น่าเบื่อ และสุดท้ายก็กลับไปสู่ปัญหาเดิมๆ ที่เคยเจอ

ปัญหานี้ไม่ได้เกิดจากตัว Scrum เอง แต่เกิดจาก “รูปแบบที่เป็นปัญหา” หรือ Anti-Patterns ซึ่งเป็นกับดักที่หลายทีมมักจะตกลงไปโดยไม่รู้ตัว

มองว่า Scrum คือ “สูตรสำเร็จ” (The “Best Practice” Trap)

กับดักแรกและเป็นรากเหง้าของปัญหาทั้งหมด คือความเข้าใจผิดที่ว่า Scrum คือชุด “แนวทางปฏิบัติที่ดีที่สุด” (Best Practices) หรือสูตรสำเร็จที่สามารถหยิบไปใช้ได้กับทุกสถานการณ์

ทำไม “สูตรสำเร็จ” ถึงใช้ไม่ได้ผล?

โดยธรรมชาติแล้ว งานที่ทีม Scrum ทำส่วนใหญ่มักเป็นงานที่มีความ ซับซ้อน (complex) ซึ่งหมายความว่าเราไม่สามารถคาดเดาผลลัพธ์ทุกอย่างได้ล่วงหน้า ไม่มีใครมีคำตอบที่ถูกต้องที่สุดตั้งแต่แรก การยึดติดกับ “สูตรสำเร็จ” เพียงสูตรเดียวจึงเป็นการปิดกั้นการเรียนรู้และการปรับตัว

หัวใจของ Scrum คือหลักการของประสบการณ์นิยม Empiricism (ความรู้ทั้งหมดมาจากประสบการณ์และการสังเกตทางประสาทสัมผัส) ซึ่งประกอบด้วย 3 เสาหลัก คือ

  1. ความโปร่งใส (Transparency): ทุกคนมองเห็นภาพเดียวกัน
  2. การตรวจสอบ (Inspection): หมั่นตรวจสอบผลงานและความคืบหน้าอย่างสม่ำเสมอ
  3. การปรับตัว (Adaptation): พร้อมที่จะปรับเปลี่ยนแผนและวิธีการเมื่อได้เรียนรู้สิ่งใหม่

การบังคับใช้ “Best Practice” จึงขัดแย้งกับหลักการเหล่านี้โดยตรง เพราะมันบอกให้เราทำตามขั้นตอนที่ตายตัว แทนที่จะเรียนรู้และปรับตัวไปตามสถานการณ์จริง

เคน ชวาเบอร์ (Ken Schwaber) ผู้ร่วมก่อตั้ง Scrum มักกล่าวว่า Scrum นั้นใช้เวลาเพียงครู่เดียวในการทำความเข้าใจ แต่ต้องใช้เวลาตลอดชีวิตในการเชี่ยวชาญ ซึ่งบ่งชี้ว่าการนำไปใช้นั้นยากเพราะสภาพแวดล้อมมีความซับซ้อน

เมื่อสูตรสำเร็จแฝงตัวมาในชื่อ Scrum

ปัญหานี้มักจะปรากฏในรูปแบบที่เรียกว่า “Water-Scrum-Fall” ซึ่งเป็นการนำกระบวนการทำงานแบบลำดับขั้น (Waterfall) ที่คุ้นเคย มาสวมหน้ากากของ Scrum ตัวอย่างที่เห็นได้ชัดคือ

  • คู่มือ Scrum 500 หน้า: องค์กรสร้างคู่มือที่ระบุกระบวนการและ “แนวทางปฏิบัติ” ทุกขั้นตอนอย่างละเอียด จนไม่ต่างอะไรจากคู่มือการทำงานแบบ Waterfall เดิมๆ
  • สปรินต์เฉพาะทาง (Specialized Sprints): ทีมสร้างสปรินต์ที่เลียนแบบขั้นตอนของ Waterfall เช่น Sprint Zero: สปรินต์สำหรับการวางแผนและออกแบบทั้งหมดล่วงหน้า Design Sprint, Development Sprint, Test Sprint: แบ่งงานออกเป็นส่วนๆ ตามทักษะ ทำให้เกิดการรอคอยและส่งมอบงานได้ช้า Hardening Sprint: สปรินต์สุดท้ายสำหรับเก็บตกงาน แก้บั๊ก และทดสอบ ซึ่งเป็นข้ออ้างในการปล่อยให้งานที่ไม่มีคุณภาพหลุดรอดออกมา

พฤติกรรมเหล่านี้มีรากฐานมาจากความคิดแบบ Taylorism (Frederick Winslow Taylor, 1911) ซึ่งเป็นแนวคิดการจัดการในยุคอุตสาหกรรมที่มุ่งเน้นความแน่นอนและการทำตามคำสั่ง ซึ่งเหมาะกับงานในโรงงาน แต่ใช้ไม่ได้ผลกับงานที่ต้องใช้ความคิดสร้างสรรค์และความรู้

การนำ Scrum มาใช้ในองค์กรที่คุ้นเคยกับการทำงานแบบ Taylorism จึงเป็นการต่อสู้ที่ยากลำบาก การที่ Product Backlog ไม่มีการเปลี่ยนแปลง (Static Product Backlog) หรือการที่ผู้จัดการมุ่งเน้นที่การใช้งานทรัพยากร (Resource Utilization) 100% ก็เป็นผลมาจากการโหยหาความแน่นอนนี้

การพยายามทำให้ Scrum เป็นสูตรสำเร็จที่ตายตัวนี้เอง ที่นำเราไปสู่ปัญหาถัดไป นั่นคือการทำ Scrum แบบหุ่นยนต์

อาการที่แสดงออก — “Scrum แบบหุ่นยนต์” (Mechanical Scrum)

เมื่อทีมถูกบังคับให้ทำตาม “สูตรสำเร็จ” โดยไม่เข้าใจถึงแก่นแท้และคุณค่าของมัน ผลลัพธ์ที่ได้คือ Mechanical Scrum หรือ “Scrum หุ่นยนต์”

Mechanical Scrum คือการที่ทีมทำกิจกรรมต่างๆ ของ Scrum เช่น Daily Scrum, Sprint Review หรือ Sprint Retrospective ไปเพียงเพื่อ “ติ๊กช่องว่าทำแล้ว” (check off a list) การทำงานร่วมกันจะรู้สึกเหมือนถูกบังคับและไร้ชีวิตชีวา ทุกอย่างกลายเป็นเพียงพิธีกรรมที่น่าเบื่อ

สิ่งที่หายไปคือ “จิตวิญญาณ” ของ Scrum

หัวใจที่ขาดหายไปของ Mechanical Scrum คือ ค่านิยมของ Scrum (Scrum Values) 5 ประการ ได้แก่

  1. ความกล้าหาญ (Courage): กล้าที่จะพูดความจริง ทำในสิ่งที่ถูกต้อง และเผชิญหน้ากับปัญหาที่ท้าทาย
  2. การมุ่งเน้น (Focus): ทุ่มเทให้กับเป้าหมายของ Sprint และสร้างความก้าวหน้า
  3. ความมุ่งมั่น (Commitment): มุ่งมั่นที่จะบรรลุเป้าหมายร่วมกันเป็นทีม
  4. ความเคารพ (Respect): เคารพซึ่งกันและกันในฐานะคนทำงานมืออาชีพ
  5. การเปิดกว้าง (Openness): เปิดเผยเกี่ยวกับงานและความท้าทายที่เจอ

หากไม่มีค่านิยมเหล่านี้เป็นแนวทาง Scrum ก็จะกลายเป็นเพียงโครงสร้างที่ว่างเปล่า ทีมจะกลายเป็นแค่ “คนตัดไม้แบ็กล็อก” (backlog lumberjacks) ที่ทำงานไปวันๆ โดยไม่เข้าใจว่าสิ่งที่ทำนั้นมีเป้าหมายหรือสร้างคุณค่าอะไร

การทำ Scrum แบบหุ่นยนต์และไร้จิตวิญญาณนี้ จะกัดกร่อนสิ่งที่สำคัญที่สุดในการทำงานร่วมกัน ซึ่งนำไปสู่ผลลัพธ์สุดท้ายที่ร้ายแรงที่สุด

ผลลัพธ์ร้ายแรง — เมื่อ “ความไว้วางใจ” หายไป (Missing Trust)

ผลกระทบที่ร้ายแรงที่สุด คือการที่ ความไว้วางใจ (Trust) ในทีมและองค์กรถูกทำลายลง ความไว้วางใจคือรากฐานของ ความโปร่งใส (Transparency) ซึ่งเป็นเสาหลักต้นแรกของ Scrum หากปราศจากความไว้วางใจ ก็จะไม่มีความโปร่งใสที่แท้จริง เมื่อไม่มีความโปร่งใส เราก็ไม่สามารถตรวจสอบและปรับตัวได้อย่างมีความหมาย ทำให้ Scrum ทั้งระบบพังทลายลง

เมื่อความไว้วางใจขาดหายไป จะเกิดเหตุการณ์เหล่านี้

  • ทุกคนเล่นเกมป้องกันตัว: แทนที่จะร่วมมือกันแก้ปัญหา ทีมกลับเริ่มกล่าวโทษกันและกัน
  • ปัญหาถูกซ่อนไว้ใต้พรม: ไม่มีใครกล้าพูดถึงปัญหาที่แท้จริง เพราะกลัวว่าจะถูกตำหนิ
  • ความโปร่งใสจอมปลอม: ทีมอาจนำเสนอ “งานที่ยังไม่เสร็จ” ใน Sprint Review เพื่อให้ดูเหมือนว่ามีความคืบหน้า ซึ่งท้ายที่สุดแล้วจะทำลายความเชื่อมั่นของผู้มีส่วนได้ส่วนเสีย (Stakeholders)

จะสร้างความไว้วางใจกลับคืนมาได้อย่างไร?

การฟื้นฟูความไว้วางใจไม่ใช่เรื่องง่าย แต่สามารถทำได้ โดยมี Scrum Master เป็นผู้ที่มีบทบาทสำคัญในการขับเคลื่อน ซึ่งแนวทางที่ดีที่สุดคือ

  1. ส่งมอบผลิตภัณฑ์ที่ใช้งานได้จริงอย่างสม่ำเสมอ: ไม่มีอะไรจะสร้างความไว้วางใจได้ดีไปกว่าการส่งมอบ Increment ของผลิตภัณฑ์ที่ “เสร็จสมบูรณ์” (Done) และมีคุณค่าในทุกๆ สปรินต์ การลงมือทำให้เห็นผล คือเครื่องพิสูจน์ที่ดีที่สุด
  2. นำค่านิยม Scrum กลับมาใช้: โดยเฉพาะ การเปิดกว้าง (Openness) และ ความกล้าหาญ (Courage) เพื่อสร้างพื้นที่ปลอดภัยให้ทุกคนกล้าที่จะพูดความจริงและยอมรับปัญหา

การเดินทางของความล้มเหลวในการใช้ Scrum มักเริ่มต้นจากความเข้าใจผิดที่พยายามจะเปลี่ยนมันให้เป็น “สูตรสำเร็จ” ซึ่งนำไปสู่การทำ “Scrum แบบหุ่นยนต์” ที่ไร้จิตวิญญาณ และท้ายที่สุดมันจะทำลาย “ความไว้วางใจ” ซึ่งเป็นหัวใจสำคัญที่ทำให้ Scrum ทำงานได้

Scrum ไม่ใช่ชุดของกฎเกณฑ์ที่ต้องทำตามอย่างเคร่งครัด แต่เป็น กรอบการทำงาน (Framework) ที่ส่งเสริมให้ทีมเรียนรู้และปรับตัวเพื่อรับมือกับปัญหาที่ซับซ้อน

การจะทำให้ Scrum ประสบความสำเร็จได้นั้น องค์กรและทีมจะต้องก้าวข้ามเพียงแค่ “การทำ” Scrum ไปสู่ “การเป็น” Scrum อย่างแท้จริง โดยยึดมั่นในหลักการและค่านิยม เพื่อสร้างสภาพแวดล้อมที่เต็มไปด้วยความไว้วางใจและความโปร่งใส