ถอดรหัส SCRUM Guide 2020
ปัจจุบัน SCRUM ยังคงเป็น Framework ยอดนิยมตัวหนึ่งในหลายๆองค์กร สำหรับการเริ่มต้นนำแนวความคิดแบบ Agile ไปใช้ สมาชิกในทีมพัฒนาจำนวนเยอะขึ้นเรื่อยๆได้มีการนำ Practice ต่างๆไปใช้และมีความคุ้นเคยกับ SCRUM มากขึ้น และจากสถิติ ก็ระบุว่าทีมที่นำ SCRUM ไปใช้อย่างถูกต้อง สามารถช่วยให้ทีมทำงานร่วมกันและเพิ่มประสิทธิภาพได้มากขึ้นอย่างน้อยถึง 300%
แต่หากถามว่ารู้จัก หรือเคยอ่าน SCRUM Guide หรือไม่
คงมีคนจำนวนไม่น้อย ส่ายหัว หรือถามกลับมาว่า “มันคืออะไร” บทความนี้จึงอยากมาช่วยให้ผู้อ่านและผู้ที่สนใจใน SCRUM รับรู้ถึงบทบาทและความสำคัญของ SCRUM Guide กันครับ ซึ่งสำหรับผู้เขียนแล้ว ผมว่าเป็นจุดเริ่มต้นที่ดี และแม้ว่าจะเคยอ่านแล้วก็ควรติดตามเกี่ยวกับการเปลี่ยนแปลงต่างๆ ที่เกิดขึ้นใน SCRUM Guide เพราะว่า แม้แต่ตัว Guide เอง มันก็เป็นส่วนหนึ่งของการ Inspect & Adapt ตาม ever-growing complex world เช่นกัน
What is SCRUM Guide?
ตัว SCRUM ถูกคิดค้นมาตั้งแต่ปี 1990 และหลังจากนั้น 20 ปี SCRUM Guide edition แรกจึงถูกเขียนขึ้นเมื่อปี 2010 โดยมีเป้าหมายคือ สร้างความเข้าใจเกี่ยวกับ SCRUM จริงๆตัวชื่อมันก็บอกอยู่แล้วว่าเป็น Guide หมายความว่าเราใช้ในการนำทาง สามารถประยุกต์ได้ตาม context และสถานการณ์ เนื้อหาใน Guide จึงไม่ได้เป็นกฎข้อบังคับ (ซึ่งก็จริง ใครจะบังคับเราได้ คงไม่มีตำรวจ SCRUM มาจับเราหรอกจริงไหม) ปัจจุบัน SCRUM Guide ได้ถูกเขียนขึ้นมาเป็น edition ที่ 6 ในปี 2020
บทความนี้ไม่ได้มาอธิบายเนื้อหาทั้งหมดเพราะด้วยตัว Guide ที่มีเพียง 14 หน้า (รวมหน้าปกแล้ว) ก็สั้นพอที่จะอ่านจบได้ภายใน 1 ชั่วโมง แต่ผู้เขียนอยากจะมาเล่าว่าสิ่งที่เปลี่ยนแปลงไปใน edition 6 เมื่อเทียบกับ edition 5 คืออะไร และเหนือสิ่งอื่นใดคือ “เพราะอะไร”
1. Clearer, Simpler, Wider
SCRUM Guide ใน edition ที่ 5 มีจำนวนหน้าทั้งหมด 19 หน้า ซึ่งถือว่าสั้นมากแล้วเมื่อเทียบกับ Guide หรือ Body of Knowledge อื่นๆ (อ้างอิง PMBOK edition 6 ซึ่งมี 756 หน้า ไม่รวม Agile Practice Guide) แต่ SCRUM Guide ใน edition ปัจจุบันมีเพียง 14 หน้า หรือจำนวนหน้าลดลงมากกว่า 25% ซึ่งสาเหตุหลักๆมาจาก
- Clearer : การลดความซับซ้อนของรูปประโยคเพื่อความเข้าใจที่ง่ายขึ้น
- Simpler : รูปแบบ กระบวนการ และ ข้อมูลเชิงลึกต่างๆ ถูกคัดกรองออกไปให้เหลือแต่แก่นของ SCRUM ที่แท้จริงเท่านั้น โดยที่ Guide ระบุว่าวิธีการนำไปใช้นั้นมีความหลากหลายขึ้นอยู่กับสภาพและสถานการณ์ (context-sensitive)
- Wider : ตัดเนื้อหาในส่วนที่มีความเป็น IT หรือ Software ออก เช่น การทดสอบ การออกแบบ การเก็บความต้องการ เป็นต้น เนื่องจาก SCRUM แม้ว่าเริ่มต้นจะถูกออกแบบเพื่อโครงการพัฒนา Software แต่ปัจจุบันถูกใช้แพร่หลายในอุตสาหกรรมอื่นๆเช่นกัน จะสังเกตได้จากการที่ wording บางอย่างได้หายไปจาก Guide อย่างมีนัยสำคัญ เช่น “requirement”, “test”, “architecture”
2. “Developers” not “Development Team”
ใน edition นี้ Ken & Jeff (ผู้คิดค้น SCRUM) พยายามเน้นความเป็น team เดียวกันมากขึ้น และตัดคำว่า Team ออก จาก “Development Team” และแทนผู้พัฒนาด้วยคำว่า “Developers” แทน ผู้อ่านบางท่านอาจจะรู้สึกว่าเรื่องเล็ก แต่สำหรับการทำงานร่วมกันแล้ว ผมว่าการสร้างสรรพนามในจิตใจ “พวกฉัน” และ “พวกเขา” ส่งผลไม่ดีต่อความร่วมมือมากๆๆๆๆๆ ซึ่งใน SCRUM ก็มีแค่ 3 บทบาท คือ Scrum Master, Product Owner, และ Developers หากใช้คำว่า Development Team อาจทำให้ผู้พัฒนารู้สึกว่า Product Owner และ Scrum Master ไม่ใช่ “พวกฉัน” ขึ้นมาได้ ประมาณว่าคุณคือคนนอก และคนนอกก็คงได้รับความเชื่อใจน้อยกว่าพวกเดียวกันเอง การเปลี่ยนแปลงเล็กๆนี้จึงเป็นการเพิ่ม Trust ให้กับทีมด้วยการใช้คำว่า “พวกเรา” แทน
3. Product Goal
ใน SCRUM Guide จะมีการพูดถึง Sprint Goal มาตลอดทุก edition ซึ่งจะช่วยตอบคำถามผู้พัฒนาว่าเราพัฒนา Increment ใน Sprint Backlog นี้ไปทำไม และในบทบาทที่คล้ายคลึงกัน Product Goal ได้ถูกนิยามขึ้นเพื่อให้ทั้งทีม เข้าใจว่าเราพัฒนา Product นี้ไปทำไม ที่ผ่านมาส่วนใหญ่ Guide จะพูดถึง Vision เป็นหลัก แต่ด้วยความที่ Vision จะต้องมีความทะเยอทะยาน เป้าใหญ่ อลังการ ตัวอย่างเช่น
- Amazon — To be Earth’s most customer-centric company, where customers can find and discover anything they might want to buy online.
- Apple — To bring the best user experience to its customers through its innovative hardware, software, and services.
- Disney — To be one of the world’s leading producers and providers of entertainment and information
ทำให้ Vision ดูเหมือนจะเป็นสิ่งที่จับต้องยากและห่างไกลจากผู้พัฒนาที่อาจกำลังพัฒนาเพื่อตอบโจทย์ที่เล็กๆบางอย่างในแต่ละ Sprint และด้วยเหตุผลนี้เอง การนิยาม Product Goal ที่สามารถเชื่อมโยงเจตนาของ Product Owner และ ความพยายามของ Developers ได้จึงถูกนำเสนอและเน้นย้ำขึ้น
ใน Product ที่มี SCRUM team มากกว่าหนึ่งทีมก็ควรที่จะแชร์ Product Owner, Product Backlog, รวมถึง Product Goal เดียวกันด้วย (มีบทความน่าสนใจเกี่ยวกับตัวอย่างของ Product Vision > Product Goal > Sprint Goal ที่สามารถนำไปประยุกต์ใช้ได้ ที่ link)
4. Artifact Commitment
“commitment” เป็นหนึ่งใน SCRUM values ที่ SCRUM team ทุกคนควรจะยึดและให้คุณค่าตลอดเวลา (และถูกระบุไว้ใน SCRUM guide เช่นกัน)
The Scrum Team commits to achieving its goals and to supporting each other.
Artifact ใน SCRUM มีแค่ 3 ตัวเท่านั้น Product Backlog, Sprint Backlog, Increment ซึ่ง SCRUM Practitioner รู้ดีว่าทุก Sprint ต้องมี Sprint Goal, ทุก Increment ต้องผ่าน Definition of Done ก่อน แต่ในเมื่อมันจำเป็นต้องมี ทำไมไม่ถูกระบุเป็น Artifact เพราะฉะนั้นใน edition นี้จึงได้ทำการระบุสิ่งเหล่านี้เป็นส่วนหนึ่งของ Artifact โดยกล่าวว่าเป็น commitment หรือเป็นสิ่งที่ทั้งทีมต้องยึดถือและปฏิบัติตามให้ได้สำหรับ Artifact เหล่านั้นเช่น
- ถ้า Product Owner กำหนด Product Backlog Item ที่ไม่ตอบโจทย์ Product Goal ทีมควรจะต้องตั้งคำถามและขอคำอธิบายเพิ่มเติม
- ถ้างานใน Sprint ที่ผู้พัฒนาทำมีความขัดแย้งต่อ Sprint Goal อาจต้องมีการเจรจากับ Product Owner ใน scope ของ Sprint Backlog เพื่อกำจัดความขัดแย้งนั้น (ไม่เปลี่ยน Goal)
- ถ้าจะเปลี่ยนจาก Backlog Item หนึ่งเป็น Increment จะต้องผ่าน Definition of Done ก่อน ถ้าไม่ผ่านก็ต้องทำเพิ่มเติม ไม่ควรหละหลวม และปล่อยผ่าน
5. Self-managing Team
แปลตรงๆ และจากที่อ่านบทความจากหลายๆท่านมา ส่วนใหญ่ก็จะบอกว่า Self-managing และ Self-organizing ไม่ได้มีความแตกต่างเท่าไหร่ การเปลี่ยนคำๆนี้ทำให้เกิดความสับสน และไม่ควรเปลี่ยน
แต่จากที่ผมพยายามเปรียบเทียบระหว่าง edition 2017 และ edition 2020 ผมพบข้อสังเกตในความหมายที่ Jeff & Ken แอบแฝงไว้อยู่
- คำว่า “self-organizing” ปรากฎอยู่ใน edition 2017 จำนวน 6 ตำแหน่ง และ 5 ใน 6 ตำแหน่งนั้น ใช้คำนี้สำหรับ Developers เท่านั้น
- คำว่า “self-managing”/ “self-management” ปรากฎอยู่ใน edition 2020 จำนวน 4 ตำแหน่ง และทั้งหมดถูกใช้กับ SCRUM team หรือ team members
ผมกำลังจะบอกว่า มันเชื่อมโยงกับข้อแรกในบทความนี้ว่า เราคือทีมเดียวกัน และบุคคลสำคัญคนหนึ่งในนั้นคือ Product Owner การควบรวมและไม่แบ่งแยก รวมถึงการให้ความสำคัญต่อ Autonomy ของทีม (การปกครองตนเอง) จึงเป็นสาเหตุของการเปลี่ยนคำนี้จาก
self-organizing : … They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality …
เป็น
self-managing : … They are also self-managing, meaning they internally decide who does what, when, and how…
6. Sprint Value
SCRUM guide edition 5 ปี 2017 มีการระบุคำถามสองคำถามที่จำเป็นต้องตอบในระหว่างการทำ Sprint Planning คือ เราจะทำอะไรบ้างใน Sprint (What?) และ เราจะทำอย่างไร (How?) ซึ่งจุดประสงค์ของ Sprint หรือ Sprint Goal (Why?)นั้นถูกแยกออกมาเป็นอีกเรื่องหนึ่ง
เพื่อเรียงลำดับและช่วย SCRUM team ให้เข้าใจง่ายขึ้น ใน edition ปัจจุบันจึงทำการจัดเรียงเนื้อหาใหม่ในรูปแบบ WHY -> WHAT -> HOW โดยเพิ่มหนึ่งคำถามแรกขึ้นมาคือ เราทำไปทำไม
Why is this Sprint valuable?
Value หรือคุณค่าในที่นี้ หมายถึง คุณค่าสำหรับ Stakeholders ของ Product ที่เราทำ ไม่ใช่สำหรับ SCRUM team เอง โดยใน SCRUM Guide ระบุไว้ว่า SCRUM team จะต้องช่วยกันกำหนด Sprint Goal ขึ้นมาระหว่าง Sprint Planning ความเห็นส่วนตัวของผู้เขียนคือการกำหนดขึ้นมาก่อนล่วงหน้าอาจทำได้ แต่ก็ต้องยอมรับการเปลี่ยนแปลงที่เกิดขึ้นระหว่าง Sprint Planning อยู่ดี
7. Leading and Servicing Rebalance
ผู้ที่คุ้นเคยกับหน้าที่ Scrum Master คงเคยได้ยินคำว่า Servant Leadership มาพอสมควร โดยที่ด้วยธรรมชาติของหน้าที่นี้คือ พวกเขาไม่ใช่ Project manager ที่มีบทบาทเน้นไปทาง command-and-control แต่เป็นผู้เชี่ยวชาญ (Master) ใน Framework SCRUM ที่เน้นให้ Cross-functional ทีม Self-manage (สามารถอ่านเพิ่มเติมเกี่ยวกับ ความแตกต่างของสองบทบาทนี้ได้ที่ Project Manager และ Scrum Master สองคนในร่างเดียว) ด้วยเหตุนี้ Scrum Master จึงมีหน้าที่ในเชิงให้บริการต่างๆเช่น
- จัดเตรียมสิ่งแวดล้อม
- สนับสนุนแนวทางการทำงาน
- เสริมสร้างความเข้าใจกับผู้บริหารและคนอื่นๆในองค์กร
- แก้ปัญหาที่ส่งผลกระทบต่อการทำงานใน Sprint
- ช่วยเหลือทีมงานทุกคนให้เข้าใจจุดประสงค์ของแต่ละ SCRUM Events
- อื่นๆ
แนวความคิดนี้ยังคงไม่ได้เปลี่ยนไปใน edition ปัจจุบัน เพียงแต่ Ken & Jeff คงอยากพยายามสื่อสารต่อผู้ที่นำ SCRUM ไปใช้ด้วยว่า Scrum Master ไม่ว่าอย่างไรก็เป็นบทบาทสำคัญในการขับเคลื่อนความก้าวหน้าโครงการและการพัฒนาของทุกคนภายในทีม ซึ่งนั่นก็คือ Leader
เพื่อไม่ให้เกิดความเข้าใจผิดว่า Servicing มีความสำคัญมากกว่า Leading ผู้เขียนจึงสันนิษฐานว่า SCRUM จึงพยายามสื่อด้วยการลบคำว่า “Servant Leadership” นี้ออกจาก edition ปัจจุบันนั่นเอง (สามารถอ่านเพิ่มเติมเกี่ยวกับ Servant Leadership ได้ที่ Scrum Master ไปให้เหนือกว่าการเป็น Servant Leader)
What comes next?
ในอนาคตอันใกล้ เมื่อโลกเปลี่ยนไป กาลเวลาเปลี่ยนแปลง การคงอยู่ของ SCRUM ก็อาจจะต้องได้รับการ Inspect & Adapt เพื่อให้ทันต่อยุคสมัย ซึ่ง SCRUM Guide แต่ละ edition เป็นทั้งหลักฐานและเป็นทั้งการแสดงความสอดคล้องต่อ Agile Mindset ที่ดี ที่จะไม่ยึดติดกับเรื่องหนึ่งๆ และ ยินดีที่จะปรับปรุงเพื่อสร้าง Value ต่อพวกเราซึ่งคือ SCRUM users หรือ Stakeholders ของ Product (SCRUM Framework) ที่พวกเขาพัฒนาขึ้น
แม้แต่ SCRUM ก็ยังเปลี่ยนแปลง แล้วทำไมเราถึงจะไม่เปลี่ยนไป
ผู้ที่สนใจสามารถศึกษาประวัติการเปลี่ยนแปลงของ SCRUM Guide ในแต่ละ edition ได้ที่ SCRUM Guide Revisions
Author Biography
Werachart Ratanatharathorn (Yim) [PfMP, PMP, A-CSM, CSPO] has more than 15+ years in project management. Currently holding a position of Head of Projects at MAQE. He has a strong passion for organizational project delivery and team psychology.
