ฤา Scrum จะทำให้ Agile พัง!
ก่อนหน้าที่คุณจะเริ่มลองใช้ Agile คุณคงค้นพบว่าการทำงานแบบ Waterfall ไม่โอเค Agile น่าจะช่วยตอบโจทย์มากกว่า พอจะลองใช้ ก็มีแต่คนแนะนำ Scrum แต่หลังจากที่เริ่มทำ Scrum ไปจริงๆ นี่สิ… ทำไมมัน “พัง” กว่าเดิมนะ
เล่นจั่วหัวเรียกแขกกันแบบนี้เลย! ทั้งนี้ต้องทำความเข้าใจก่อนว่าบทความนี้ไม่ได้จะมาบอกว่า Scrum มันไม่ดีแต่อย่างใดนะ ค่อยๆ อ่านไปจนจบด้วยกันครับ :P
สวัสดีครับ ตอนนี้ทีมคุณกำลังทำ Agile โดยใช้ Scrum กันอยู่หรือไม่ ถ้าใช่ ชีวิตเป็นอย่างไรบ้าง
- มีความสุขกว่าเดิมที่ได้ส่งมอบงานทุกๆ Sprint
- มีความสุขที่ได้คุยกับ Business บ่อยๆ เพื่อเปลี่ยน Requirement
- จบทุก Sprint แล้วมีของที่สามารถขึ้น Production ได้เลย อะ… รอ Integration Test อีกสัก 2–3 Sprint แล้วกัน
- มีความสุขที่ได้ทำ Estimation ทุกครั้งเลย
- User Story: As a… ทำให้เราเห็นภาพตรงกันนะ
ถ้าคุณมีความสุขขนาดนั้นแล้ว ก็ข้ามบทความนี้ไปครับ 555 แต่ถ้าคุณไม่ได้รู้สึกแบบนั้น เพราะพบเจอปัญหาบางอย่างจากการใช้ Scrum เราคือเพื่อนกัน
Scrum ไม่ใช่ Agile!
Scrum เป็นเครื่องมือหนึ่งที่ถูกนำมาปรับใช้เพื่อให้เกิด Agility และเข้าใกล้นิยามของคำว่า Agile มากขึ้น เนื่องจาก Scrum เป็นเครื่องมือที่มีรูปแบบ(เกือบ)ชัดเจน มีกระบวนการ, Role, Ceremony และ Output ที่ระบุไว้ให้ทำตาม ทำให้หลายที่มองว่า Scrum เป็นจุดเริ่มต้นที่ดีที่จะนำมาใช้ เพื่อให้เรา Agile มากขึ้น
ซึ่งความเข้าใจดังกล่าวไม่ผิดอะไรเลยครับ เพียงแต่ที่ผ่านมาการปรับใช้กลายเป็นการยึดโยง แทนที่จะนำมาปรับใช้ให้เหมาะสม หลายคนกลับตั้ง Scrum เป็นบทบัญญัติที่ต้องทำตาม ต้องมี/ต้องเป็นตามนี้เท่านั้นนะ หรือบางครั้งก็ปรับกันไปจนหลุดออกจากวัตถุประสงค์ของ Scrum
ปัญหาที่อยากชวนทุกคนคิดคือ…
เราเอา Scrum มาใช้เพื่ออะไร?
ถ้าบอกว่าเราอยากเป็น Agile อยากทำ Agile แล้วเราอยากทำมันไปเพื่ออะไรนะ? ตอนนี้บริษัทหรือองค์กรเรามีปัญหาอะไรที่อยากแก้ แล้วคิดว่าจะนำ Agile มาแก้ให้เกิด Outcome อะไร ที่เราเลือกเครื่องมือ Scrum มาใช้เหมาะสมกับสิ่งที่เราเป็นอยู่หรือสิ่งที่เราอยากให้เป็นไหม เราพร้อมที่จะ Inspect and Adapt หรือเปล่า
หลายครั้งการที่เรานำ Scrum มาใช้ เราเปลี่ยนทุกอย่างให้ตรงตามที่ Scrum Guide บอก พร้อมกับเอาบางอย่างที่ Scrum Guide ไม่ได้บอก พอเสร็จก็ชี้ว่านี่แหละการ Customize ของเรา… แต่ Customize จนเผลอลืมไปว่าเราหยิบมันมาใช้เพื่อแก้ปัญหาที่มีอยู่นะ ไม่ใช่เอามาเพิ่มปัญหาใหม่
ชำแหละ Scrum
ออกตัวก่อนดีกว่า ผมก็ไม่ได้เก่งและเชี่ยวชาญขนาดจะมาบอกว่า Scrum มันผิดหรือใช้ไม่ได้นะครับ แต่ผมขอมาแชร์จากประสบการณ์ตัวเองแล้วกันว่าพอเราเอา Scrum มาใช้ แต่ละจุดมีพบเจอปัญหาอะไรบ้าง
Scrum Role
อันดับแรกกกกก เวลาคุณใช้ Scrum ส่วนใหญ่จะเริ่มที่ Scrum Role เรามี Role ตรงตามนี้หรือยังนะ เอ้า ไม่มีเหรอ เปลี่ยนสิ
- PM >> SM?
- BA >> PO?
- UX/UI >> PO?
- Dev >> Team?
- QA >> Team?
- SA >> Team?
ปัญหาเริ่มจากตรงนี้แหละครับ ก่อนจะปรับ เราเข้าใจหรือยังว่าแต่ละ Role ต้องรับผิดชอบอะไร จุดประสงค์เพื่อให้เกิดอะไร และแต่ละฝ่ายต้องมีอำนาจการตัดสินใจในส่วนไหน
ก่อนจะปรับ Role เราควรเริ่มที่ Flow งาน Flow ของการทำงานเราเป็นอย่างไร Requirement เข้ามาทางไหน ที่เป็นอยู่มีใครเกี่ยวข้องบ้าง ใครต้องทำอะไร ส่งมอบงานกันอย่างไร งานที่ทำอยู่ต้องใช้ Skill อะไรบ้าง กระบวนการจากต้นจนจบ ตั้งแต่เริ่มมีความคิดที่จะทำจนถึงส่งมอบของให้ผู้ใช้งานนั้นมีอะไรบ้าง แล้วในกระบวนการเหล่านั้นเราเจอปัญหาตรงจุดไหน เราต้องการปรับกระบวนการนั้นเพื่อแก้ปัญหาอะไรบ้าง ซึ่งสุดท้ายอาจจะนำไปสู่การค้นพบว่าเราไม่ต้องปรับทุกคนให้มี Role ตรงตาม Scrum ก็ได้ เพียงแค่ต้องมีคนที่สามารถ Respond and Act ให้ตรงตามวัตถุประสงค์ของ Role ใน Scrum ต่างหาก
PO: Product Owner
ใครกันเล่าจะเป็น PO เมื่อใช้ Scrum สิ่งแรกที่ตามหากันเหลือเกินก็คือ PO ซึ่ง Scrum บอกว่าคุณต้องเอาฝั่ง Business คนที่เป็นเจ้าของ Product ตัวจริงมาเป็นนะ ต้องเป็นคนที่ตัดสินใจได้ แถมต้องเขียน Requirement ได้ด้วยนะ พลันสายตาก็เหลือบมองไปยัง Senior BU คนที่เป็นเจ้าของ Product ยังไม่ทันจะเอ่ยปาก เขาก็บอกกลับมาทันทีว่าเขาเป็นไม่ได้หรอก เขายุ่งเกินกว่าจะไปลงแรง 100% กับทีม
วิธีแก้ปัญหาโดยทั่วไปคือการเอาคนที่อยู่ในทีม BU มาตั้งเป็น PO แล้วอาจจะเอา BA ไปเป็นผู้ช่วย PO อีกทีนึง ซึ่งบางทีก็เกิดปัญหาว่า PO คนนั้นไม่มีอำนาจตัดสินใจที่แท้จริง หรืออาจจะไม่รู้จัก Product จริงๆ ด้วยซ้ำ หรือบางทีก็ตั้ง PO จากทีม IT เลย ซึ่งคนนี้ไม่ได้มีส่วนได้ส่วนเสียกับ Product ถูกตั้งขึ้นมาเพราะ Scrum บอกต้องมี PO เฉยๆ เลยเอาเขามาเป็นหน้าเสื่อ คอยเข้า Meeting เขียน Requirement และคอยประสานงานเฉยๆ
การที่แนะนำว่าต้องมี PO คนเดียว จุดประสงค์คือเพื่อให้ทีมฟังการตัดสินใจขั้นสุดท้ายจากคนๆ เดียว ซึ่งเมื่อมีคนดูแล Priority แค่คนเดียวก็จะช่วยลดความยุ่งยากในการจัดสรร ถกเถียง ลดขั้นตอนการอนุมัติลงไป หนึ่งคนสามารถคิดและตัดสินใจได้ว่าอันนี้เอาไม่เอา อย่างไรก็ตามไม่ได้หมายความว่า PO จะมีผู้ช่วยไม่ได้นะ PM, SA, BA, Tech Lead, UX, UI และอื่นๆ ก็สามารถเข้ามาเป็นผู้ช่วย PO ในการทำงานได้ เพื่อให้เราเห็น Requirement ชัดขึ้นและตัดสินใจได้ง่ายขึ้นนั่นเอง
Scrum Master
ถ้าดูจาก Scrum Guide ที่อยู่ด้านบน Scrum Master คือผู้ดูแลกระบวนการใช้งาน Scrum และช่วยอำนวยความสะดวกให้ทีมทำงานในรูปแบบ Scrum ได้อย่าง “เข้าใจ” และ “ราบรื่น” หลายครั้งเราจะได้รับคำแนะนำว่า Scrum Master ควรเป็นเอกเทศ ไม่ควรถือ Role อื่นๆ ใน Scrum ไปพร้อมกัน
แต่ความเป็นจริงหาได้เป็นเช่นนั้นไม่ บางที่ก็เอา PM มาเป็น Scrum Master บางที่เอา Tech Lead มา หรือบางที่ใครจับสลากได้ก็คนนั้นแหละ กลายเป็นว่า Scrum Master มีหน้าที่ตามงานหรือบางทีก็มีหน้าที่กันงานออกจาก PO
Scrum Master แท้ควรมีบทบาทในการสร้างความ “เข้าใจ” และมองเห็นภาพรวมของทั้งกระบวนการทำงานแบบ Scrum ตั้งแต่ Discovery to Delivery ดังนั้นทางที่ดีที่สุดในการทำงานแบบ Scrum คือมีหนึ่งคน (อีกแล้ว) มาเป็น Scrum Master แต่ถ้าไม่ได้ล่ะ? เราอาจต้องดูว่าใครที่เหมาะสมและสามารถเข้ามารับหน้าที่ตรงนี้ได้ อาจจะเป็น Delivery Manager, Tech Lead หรือ Senior Dev ในทีม แต่ที่สำคัญคือทีมต้องเข้าใจด้วยว่าตอนไหนเขากำลังสวมหมวก Scrum Master อยู่ และตอนไหนเขากำลังสวมหมวก Role อื่นอยู่
Development Team
Dev Team เป็นสิ่งหนึ่งที่ดูเหมือนง่าย เพราะส่วนใหญ่เราก็จะตั้ง Developers เป็นทีม Scrum เนี่ยแหละ ไหนๆ เขาก็เป็นคน Deliver งานแล้ว แต่ถ้าดูในนิยามจริงๆ จะเห็นว่า…
- “Dev Team แต่ละคนมีความสามารถหลากหลาย จำเป็นต่อการสร้าง Increment”
- “ไม่มีทีมงานย่อย เช่น ทีมงานทดสอบ ทีมงานดูแลด้านโครงสร้าง”
ทั้งนี้ในชีวิตจริง โดยเฉพาะในระบบหรือองค์กรขนาดใหญ่ เราไม่สามารถมีทีมที่มีทุก Role ที่เกี่ยวข้องกับการส่งมอบงาน (ที่พร้อมใช้) ได้ หรือถ้าให้มีทีม ก็จะใหญ่มากเกิน 9 คนเข้าไปอีก หลายครั้งเราเลยแยก QA Tester ออกมาอีกทีม ไว้คอยทำงาน Test Sprint (ซึ่งใน Scrum ไม่มี) หรือถ้ารวมอยู่ในทีม ก็มีโอกาสที่เขาจะเหลือเวลาทำเทสแค่ 1–2 วัน แล้วมันจะไปทำทันได้อย่างไร
สำหรับผม สิ่งสำคัญที่สุดของ Dev Team ไม่ใช่ว่ามีคนทำหน้าที่อะไรบ้าง แต่ถ้าเราต้องการให้ Flow การ Deliver จบที่การเทส เราควร “Test First” ด้วยการสร้างโครงสร้างและระบบเอื้อต่อการทำงานเป็นรอบพร้อมใช้งาน เรามี Automated Test หรือยัง เราทำ Requirement แบบมี Test First มี TDD หรือยัง เรามี CI/CD หรือยัง เรามี Process ที่คล่องตัวหรือยังต้องมีการ Approve อะไรก่อนขึ้นระบบ แล้วเรามีคนที่มี Skill แบบนี้หรือยัง
จงมองภาพสิ่งที่เรามี แล้วตั้งโจทย์ว่าเราอยากปรับปรุงกระบวนการและคนแบบไหน ไม่ใช่แค่เอา Scrum มาใช้ แล้วยัดๆ ทุกอย่างลงไป
Requirement
Product Backlog หรือ Requirement เป็นสิ่งสำคัญในกระบวนการทำ Software Development โดยเฉพาะใน Scrum การที่รอบ Sprint จะเริ่มได้ จะ Estimate ได้ จะจบได้ และจะเทสสำเร็จได้ ขึ้นอยู่กับรายละเอียดที่อยู่ใน Product Backlog ทั้งนั้น
ตรงนี้ใน Scrum บอกแค่เพียงว่า เอ้ยยย คุณต้องลำดับความสำคัญของมันนะ บางทีไปมุ่งเน้นว่ามันต้องเป็นรูปแบบ User Story As a…. นะ
หรือบางทีก็มุ่งเน้นว่าทุกอย่างต้องอยู่ใน Jira นะ ทั้งที่ใจความสำคัญคือการให้ Product Backlog อยู่ในพื้นที่ที่ทุกคนเข้าถึง สามารถใช้งานได้ทุกคน และเข้าใจตรงกัน
สิ่งสำคัญจริงๆ คือรายละเอียดครับ ซึ่งเครื่องมือ Scrum ไม่ได้มีวิธีการสร้างรายละเอียดนี้ จึงอยากแนะนำว่าใครที่นำเครืองมือ Scrum มาปรับใช้ อยากให้ลองเอาเครื่องมืออื่นๆ มาช่วยในการทำ Product Backlog หรือ Requirement
ลองดูตัวอย่างการนำเครื่องมือ XP + Test-First Development มาปรับใช้ได้ที่นี่ครับ
กิจกรรมต่างๆ ของ Scrum
กิจกรรมต่างๆ ของ Scrum มีไว้เพื่ออำนวยความสะดวกให้กับการทำงานเป็นรอบ ให้แต่ละรอบมีความชัดเจนว่าถึงเวลาที่ต้องทำสิ่งนี้แล้วนะ และเพื่อให้เกิดอะไร
สำคัญที่ “ทำเพื่ออะไร” มากกว่า “ต้องทำให้ครบ”
หลายครั้งเราพบว่าปัญหาส่วนหนึ่งเกิดมาจากการทำกิจกรรมของ Scrum แล้วลืมดูไปว่าเราทำกิจกรรมนั้นไปเพื่ออะไร
- ใช้ Daily Scrum เพื่อตามงานว่าเสร็จหรือไม่ แทนที่จะเป็นพื้นที่ให้เราเห็นว่าของที่เรา Commit ไปถึงไหนแล้ว ใครติดปัญหาอะไรอยู่ ภาพรวมของทีมเป็นอย่างไร ต้องสุมหัวกันไปช่วยที่ตรงไหนก่อนนะ เรายังทำตาม Priority อยู่หรือเปล่า เป็นต้น
- Retro ที่คอยคุยกันว่า Good Bad Try แต่ลืมไปว่าพื้นที่ที่ทำ Retro ต้องเป็นพื้นที่ปลอดภัยสำหรับเราในการพูดเรื่องจริงที่ต้องการปรับปรุง รวมถึงมองภาพการปรับปรุงและติดตามผล
ลองดูตัวอย่างคำแนะนำก่อนทำ Retro ได้จากบทความนี้เลยครับ
สรุป
ผมเชื่อว่ายังมีอีกหลายกรณีของการนำ Scrum ไปใช้ แล้วดันสร้างปัญหาใหม่ แทนที่จะแก้ปัญหาเดิม ซึ่งมันไม่ใช่ความผิดของ Scrum เลย และการเอาไปใช้ก็ไม่ได้ผิดอะไรด้วยครับ อย่าท้อใจไปครับ
สิ่งที่อยากชวนคิดจากบทความนี้คือ เราต้องการแก้ปัญหาอะไร แล้วเรากำลังนำเครื่องมืออะไรไปใช้ และเราเข้าใจวิธีการใช้เครื่องมือหรือยัง
Scrum เป็นเพียงหนึ่ง Product/Project Management Framework ในการปรับใช้ Agile ถ้าเรานำมาใช้แล้วพบว่ามันขาดอะไรไป ก็สามารถนำ Framework อื่นเข้ามาใช้ร่วมได้… อย่าฝืนใช้แต่ Scrum แล้วพังกันไปนะครับ
Waterfall, Agile, Scrum ไม่ใช่ประเด็น ถ้าปัญหาเราคือ กระบวนการทำของนั้นยุ่งยากและซับซ้อนเกินไป เราก็แก้ปัญหาโดยการทำให้มันง่ายขึ้น เทสได้ง่ายขึ้น แก้ได้บ่อยขึ้นและเอาขึ้นได้ง่ายขึ้น พังแล้วรู้และเอากลับมาได้เร็ว จะทำงานวิธีไหนก็ไม่ต่างกันเลยครับ
สำหรับใครที่สนใจเรื่องราวดีๆ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ จากชาว KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech
