แปลเนื้อหามาจาก scrumprimer.org เพื่อให้คนไทยอ่านทำความเข้าใจเรื่อง scrum ที่เป็น framework หนึ่งของ agile ได้ง่าย และเร็วขึ้น

Product Backlog Refinement

คืออะไร : การแตก Item ขนาดใหญ่, วิเคราะห์, ประเมินใหม่, จัดลำดับความสำคัญใหม่ สำหรับ sprint ต่อไป
ผู้ที่เข้าร่วม : Team และ Product Owner จะต้องเข้าร่วมตลอดหากว่าทีมต้องการคนที่ช่วยให้รายละเอียดในแต่ละเรื่องในการวิเคราะห์ได้ หรือ อาจจะเข้าเฉพาะในส่วนของการให้ direction หรือ ประเมินใหม่ หรือ จัดลำดับความสำคัญใหม่อีกครั้งก็ได้ โดยอาจจะเป็นคนอื่นที่เข้าใจใน requirement และสามารถช่วยเหลือทีมได้ ส่วน ScrumMaster จะเข้าตลอดในช่วงแรกๆที่ต้อง coach ทีมเพื่อให้เกิดประสิทธิภาพ แต่เมื่อคงตัวแล้ว ก็ไม่จำเป็น
เวลาที่ใช้ : โดยปกติจะใช้เวลาไม่เกิน 10% ของ Capacity ของทีมในแต่ละ sprint แต่ว่ามันก็อาจจะนานกว่านั้น หากว่าเป็นสิ่งที่ต้องใช้การวิเคราะห์อย่างหนักในบาง item เช่น ใน 2 สัปดาห์ของรอบ sprint จะต้องมี 1 วันที่ใช้ไปกับการทำ refinement เลย

สิ่งหนึ่งที่เราต้องเสียไปในการทำ scrum แต่ว่าให้ผลที่ดีมาก ก็คือส่วนหนึ่งของแต่ละ sprint ที่จะหยุดการทำงานของทีม เพื่อเข้ามาทำ refining หรือ Grooming product backlog เพื่อตอบโจทย์ของ sprint ต่อๆไป โดยนี่จะรวมถึง การวิเคราะห์ requirement โดยละเอียด, แบ่ง item ใหญ่ให้เล็กลง, ประเมิน item ใหม่ที่เกิดขึ้นมา หรือ ประเมินงานที่เคยประเมินไปแล้วใหม่อีกครั้ง Scrum จะไม่ได้เน้นว่าจะทำเรื่องนี้อย่างไรเพื่อให้สำเร็จ แต่ว่าเทคนิคที่จะใช้กันบ่อยๆก็คือ เน้นการ workshop ช่วงกลางหรือ ท้ายของ Sprint ดังนั้น Team และ Product Owner และ stakeholder ก็ควรจะแบ่งเวลาเพื่อทำงานงานส่วนนี้โดยที่ไม่มีอะไรเข้ามาขัดจังหวะด้วย

การทำ Refinement นี้ไม่ใช่การเลือก item เข้า sprint นี้ แต่เป็นการทำ item เพื่อจะเข้า sprint หน้า หรือ sprint ถัดไป 1-2 sprint ข้างหน้านี้ ด้วยการทำแบบนี้ Sprint Planning จึงเรียบง่าย รวดเร็ว เพราะว่า Product Owner และ Scrum team เริ่ม planning ด้วยสิ่งที่เคยพูดคุยกันมาก่อนแล้ว วิเคราะห์กันมาแล้ว รวมทั้งประเมินกันมาแล้วอย่างดี สัญญาณหนึ่งที่บอกว่า refinement workshop นี้ไม่ประสบความสำเร็จก็คือ Sprint Planning ยังมีคำถามอีกมากมาย, เกิดอาการงง, เกิดประเด็นที่พึ่งคิดได้ หรือรู้สึกว่าอาจจะไม่สำเร็จ ก็จะทำให้การ Planning ถูกลากยืดออกไปกินเวลาใน Sprint มากกว่าแผนที่วางเอาไว้ และท้ายที่สุดก็ไม่ Work

Sprint Review

คืออะไร : การตรวจรับงานที่ทำสำเร็จของ product นั้นๆ
ผู้ที่เข้าร่วม : Team, Product Owner , ScrumMaster และ stakeholder ที่เกี่ยวข้องที่ Product Owner เชิญมา
เวลาที่ใช้ : sprint ละ 1 ชั่วโมง

เมื่อจบ Sprint จะมีการทำ Sprint review โดยนำเสนอต่อ Product Owner, Team Member, Scrum Master , user , stakeholder, ผู้เชี่ยวชาญ หรือใครก็ตามที่สนใจสำหรับ 2 สัปดาห์ของ Sprint จะใช้เวลาไม่เกิน 2 ชั่วโมง และทุกๆคนมีสิทธ์ถามหรือให้ความเห็นได้หมด

เรามักจะเรียก Sprint Review ว่าเป็นการ Demo ซึ่งจริงๆแล้ว ไม่ได้มีความหมายครอบคลุมทั้งหมดของ Meeting นี้ โดยแนวความคิดหลักของ Scrum ก็คือ Inspect and adapt (ตรววจสอบและปรับปรุง) เพื่อมาดูกันว่า เกิดอะไรขึ้นบ้างในตอนนี้ รวมทั้งร่วมกันให้ feed back เพื่อไปปรับปรุงวนไปเรื่อยๆ Sprint Review นั้นเป็นเวลาสำหรับ Product Owner ที่จะได้เรียนรู้ว่าเราเดินกันมาถึงไหนแล้วไปพร้อมๆกับ Team ในขณะที่ Team ก็จะได้เรียนรู้ว่า สิ่งที่ Product Owner คิด และ ตลาด เค้าไปกันถึงไหนแล้ว ดังนั้น สิ่งที่สำคัญที่สุดของการ review ก็คือการพูดคุยกันอย่างจริงจัง ระหว่าง Team กับ Product Owner เพื่อเรียนรู้สถานการณ์ ปรึกษาขอคำแนะนำ และอื่นๆ โดยข้อกำหนดก็คือ จะต้องมี live software ที่ทีมได้สร้างขึ้นมาใน sprint นั้นๆ อย่าให้เป็นการมุ่งเน้นเพื่อนำเสนอ Product อย่างเดียว โดยไม่พูดคุยกัน นั่นไม่ถูกต้อง

Live Software ที่เอามาใช้ใน Sprint Review เป็นสิ่งที่ทีมได้สร้างขึ้นมาจริงๆ ที่ไม่ใช่ Presentation หรือ การนำเสนอ หรือมันก็คือ Software ที่สามารถรันได้ใช้งานได้จริง ซึ่งอาจจะรันอยู่ใน sandbox environment ก็ได้ โดยอาจจะมี computer เครื่องหนึ่งหรือมากกว่าใน Review room เพื่อให้คนได้ตรวจสอบการทำงานจริงๆของการใช้งาน Software นั้นๆ แนะนำว่าให้มีช่วงเวลาที่ user ตัวจริง จะได้เข้ามาใช้งาน พร้อมกับ Product Owner ดูการทำงานและตอบสนองต่อ Software มากกว่าการนำเสนอ แบบ demo ให้ user นั่งฟังอย่างเดียว สำหรับการเตรียมตัวก็ไม่ควรจะเกิน 30 นาทีสำหรับการ Prepare Sprint Review ถ้านานกว่านั้น คงมีบางอย่างผิดปกติแล้วล่ะ

Sprint Retrospective

คืออะไร : ตรวจสอบและปรับปรุง กระบวนการทำงาน และ สภาพแวดล้อม
ผู้ที่เข้าร่วม : Team , ScrumMaster, Product Owner ไม่จำเป็น และ Stakeholder อาจจะเข้ามาร่วมได้
เวลาที่ใช้ : 45 นาทีต่อ สัปดาห์ของ Sprint

Sprint Review จะเน้นที่การตรวจสอบ และ ปรับปรุงตัวงานหรือ product แต่ว่า Sprint Retrospective จะคล้ายกัน แต่เน้นที่กระบวนการทำงาน และ สภาพแวดล้อมการทำงานมากกว่า นี่เป็นการเปิดโอกาสให้ Team ได้ปรึกษากัน ว่าอะไรที่เหมาะสมแล้ว อะไรที่ยังต้องปรับปรุง รวมทั้งการตกลงบางอย่างร่วมกันว่าจะเปลี่ยนแปลงหรือแก้ไข บางครั้ง ScrumMaster จะเป็นคนที่ทำหน้าที่นำ Retrospective ตรงนี้ได้อย่างดี แต่อาจจะดีกว่าถ้ามีคนที่ดำเนินการนำ Retrospective ที่ไม่มีส่วนได้หรือเสียอะไรกับทีม ถ้าให้แนะนำก็คือ ScrumMaster นี่แหล่ะ ที่นำ Retrospective ทีมอื่นๆ แล้วก็วนๆดูและกันไป โดยไม่ใช่ทีมตัวเอง

หลายๆทีมมักจะ Retrospective แล้วได้ผลลัพท์ออกมาแต่ปัญหา นั่นไม่ถูกต้อง ควรจะทำให้การ Retrospective ได้ผลลัพท์ออกมาว่า เหตุการณ์อะไร หรือเรื่องไหน ที่ทำให้เกิดปัญหา หรือผลกระทบ ในขณะที่ต้องทำให้ทีมยังคงรักษาความคิดเชิงบวก หรือ พลังการทำงานเอาไว้ได้

หากการ Retrospective เป็นการทำงานที่ใช้เทคนิคเหมือนกับ analysis จะทำให้เกิดความน่าเบื่อ ดังนั้นก็ควรเปลี่ยนวิธีไปเรื่อยๆเพื่อให้ดูน่าสนใจอย่างต่อเนื่อง

การเริ่มต้น Sprint ต่อไป

จากที่ได้ทำ Sprint Review ผ่านมาแล้ว Product Owner จะต้องทำหน้าที่ในการปรับปรุง เปลี่ยนแปลง เพิ่ม ลด ขยับ ขยาย บีบ Product Backlog ให้ล้อไปตามสถานการณ์ ณ ตอนนั้น โดย Product Owner มีหน้าที่โดยตรงต่อการเปลี่ยนแปลงของ Product Backlog

จะไม่มีการหยุดเวลาระหว่าง sprint โดยปกติทีมจะจบวันสุดท้ายด้วยการทำ retrospective ช่วงเย็น และมาเจอกันเช้าวันถัดไปกับการทำ Sprint Planning

หลักการหนึ่งของ agile development ก็คือการ “รักษาความเร็วให้ได้อย่างต่อเนื่อง” โดยควรให้อยู่ในเวลาการทำงานโดยปกติ หรือ ตามเหมาะสมที่ทีมสามารถรักษาตรงนี้เอาไว้ได้ตลอด โดยการพัฒนาขึ้นของ Productivity ของทีมจะมาจาก ลดผลกระทบที่จะเข้ามาถึงทีมให้มาก ไม่ใช่การลดคุณภาพของการทำงานเพื่อให้ได้ productivity ที่มากขึ้น

Sprint จะต่อเนื่องไปเรื่อยๆ จนกระทั่ง Product Owner ตัดสินใจว่า product พร้อมที่จะ Release แล้ว  ถ้าเอาแบบที่ให้ตรงตามหลัก agile จริงๆ ก็คือ product นั้นพร้อมที่จะ shipable เมื่อจบ sprint แล้วจริงๆ โดยไม่มีสิ่งที่ต้องทำเพิ่มเติมเพื่อปิดท้ายอีก ไม่ว่าจะเป็นการ testing หรือ เขียน document ก็ตาม หรือหมายความว่า Product ก็จะเสร็จพร้อมใช้แล้วจริงๆ ในทุกๆการจบของ Sprint ซึ่งเราก็สามารถ deploy ได้เลย หลังจากการจบ sprint review แต่โดยทั่วๆไปแล้ว บริษัทที่มีเครื่องไม้เครื่องมือช่วยน้อย หรือมีแนวทางการพัฒนาที่ยังไม่สมบูรณ์มากพอ ก็ไม่สามารถทำตาม practice ที่สมบูรณ์แบบนี้ได้ จะต้องอาศัยการ “Release Sprint” เข้าช่วยซึ่งเป็นงานที่ต้องทำเพิ่มเติมอีกนิดหน่อยเช่นกัน หากเราต้องมีการทำ “Release Sprint” แล้วล่ะก็ คงต้องพิจารณาดูว่า ปัญหาตรงไหนที่เราต้องแก้ไขเพื่อให้ท้ายที่สุด ไม่ต้องมีกระบวนการตรงนี้ได้อีก

การบริหารการ Release

คำถามที่ถูกถามบ่อยก็คือ ทำอย่างไร หรือว่ามีแนวทางให้เดินมั้ย สามารถวางแผน release ระยะยาวให้สำเร็จได้อย่างไร คำตอบมีสองปัจจัยที่เราต้องพิจารณา 1 เป็น product ใหม่ที่เป็น first release หรือ 2 เป็น product ที่มีการ release มาก่อนแล้ว

สำหรับ product ใหม่ หรือว่า product เก่าที่พึ่งเคยปรับเข้ามาใช้ scrum จะต้องทำการสร้าง Product Backlog refinement มาก่อนเริ่ม sprint แรก โดย Product Owner และ ทีมก็จะต้องปรับตัวให้เข้ากับแนวทางของ Scrum Product Backlog ด้วย นี่อาจจะใช้เวลาหลายวัน หรืออาจจะเป็นสัปดาห์ในการเข้า workshop (บางครั้งเรียกว่า initial Product Backlog Creation หรือ Release Planning) เพื่อหาสิ่งที่ต้องการ สิ่งที่ต้องทำ วิเคราะห์ หรือ ประเมิน งานที่จะเกิดขึ้นสำหรับการทำ first release

สิ่งที่ดีงามใน Scrum ก็คือ การทำ Product โดยอาศัย Product Backlog นั้น ไม่จำเป็นต้องทำอะไรเป็นพิเศษ เพื่อที่จะต้องทำ Release Planning สำหรับการ Release ครั้งถัดไป ทำไมน่ะหรือ ก็เพราะว่า Product Owner กับทีม จะต้องทำ Product Backlog Refinement กันทุกๆ sprint อยู่แล้ว ซึ่งมันก็จะทำให้เห็นจากกิจกรรมนั้นเลย ว่าต้องทำอะไรเพิ่มเติมบ้าง การพัฒนา product อย่างต่อเนื่องแบบนี้คือสิ่งที่ต้องการที่แท้จริง เมื่อเทียบกับ การเตรียมตัว-ลงมือทำ-สรุป ที่เราจะพบใน product development โดยทั่วๆไป

ในการเริ่มต้นทำ Product Backlog refinement นั้น ระหว่างกระบวนการในแต่ละ sprint ก็จะทำให้ Team และ Product Owner วางแผนการ Release ไปแล้ว มีการประเมินอย่างดี จัดความสำคัญอย่างถูกต้อง และได้เรียนรู้สิ่งใหม่ๆเพิ่มเติมกันตลอด

บางครั้งการ Release ที่มีวันที่มากำหนด เช่น เราจะ release version 2.0 ของ project ในงาน event วันที่ 10 พฤศจิกายน ถ้าเราเจอแบบนี้ ทีมก็จะต้องทำงานให้ได้มากที่สุด จบ sprint ให้ได้มากที่สุด เท่าที่จะเป็นไปได้ ก่อนที่จะถึงวันนั้น Product ที่มีข้อกำหนดอยู่แล้ว ว่าต้องทำอะไรบ้าง และต้องทำให้มากแค่ไหน ถึงจะเพียงพอต่อการ launch แบบนี้ มักจะใช้เวลาค่อนข้างมาก แต่เมื่อเราเอา Scrum มาปรับใช้ Product Owner อาจจะต้องเป็นคนเลือกทำในบางอย่างเล็กๆขึ้นมา เพื่อลองวัดผลการใช้งาน หรือ ดูว่าใช่สิ่งที่ลูกค้าจะได้รับจริงหรือเปล่า ก่อนที่จะเอาไปทำตัวเต็มๆในอนาคต เพราะว่าเราไม่สามารถคาดเดาอะไรล่วงหน้าได้ ดังนั้น เราควรจะมุ่งเน้นที่การสร้างขึ้นมาโดยมีแผนในการ release อย่างชัดเจน และอธิบายได้ว่า อะไรที่เราต้องเอาไปแลก ไม่ว่าจะเป็น scope หรือ เวลา เป็นต้น พยายามคิดถึงเส้นทางการเดินทางนี้เอาไว้ตลอด เพื่อให้เราสามารถตัดสินใจได้ว่าเส้นทางการเดินนั้นจะเป็นอย่างไร จนกระทั่งไปถึงเป้าหมาย

การตัดสินใจนั้นมีส่วนสำคัญมากกว่าเส้นทางการเดินทาง

Product Owner ส่วนใหญ่จะเลือกแนวทางการ release แบบเดียว ก็คือการปักวันที่จะ Release เอาไว้ จากนั้น ก็มาคุยกับทีม เพื่อดูว่า Product Backlog ตัวไหนบ้างที่สามารถทำได้เสร็จก่อนถึงวันดังกล่าว โดย Item ที่พร้อมสำหรับการ release ที่จะมาถึงนั้น เราจะเรียกว่า release item ซึ่งบางครั้ง ก็มาจากสถานการณ์ที่ระบุเอาไว้แล้ว ไม่ว่าจะเป็น “มูลค่าของโครงการ / วันที่ถูกกำหนด / ข้อกำหนดการส่งมอบ” เช่น สัญญาการพัฒนา แต่ไม่ว่าอย่างไรก็ตาม อะไรที่เราจะควบคุมไม่ได้ เราก็ต้องมี buffer เผื่อเอาไว้ด้วยส่วนหนึ่งที่พร้อมจะเปลี่ยนเพราะต้องเข้าใจตรงกันอย่างหนึ่งกว่า Scrum ก็ไม่ใช่สิ่งที่จะเข้ามาเปลี่ยนแปลงอะไรเหล่านั้นได้อยู่แล้ว

Application or Product Focus
หากเป็น program หรือ product และไม่ว่าจะเป็นการสร้างเพื่อใช้ภายใน หรือ ภายนอกบริษัทก็ตาม scrum จะต้องทำการเปลี่ยนจาก project centric ให้มาเป็น การพัฒนา application/product development อย่างต่อเนื่อง ทำให้ไม่มีจุดเริ่มของ จุดกลาง และ จุดที่สำเร็จ ที่แน่ๆก็คือ ไม่มี Project Manager อีกต่อไป แต่จะมาแทนที่ด้วย Product Owner และทีมที่ self management ได้อย่างถาวร รวมทั้งการประสานงานกันอย่างไม่มีจุดจบ ด้วยระยะเวลาของ sprint อย่างคงที่ จนกว่าจะเลิกทำ Product นั้นกันไปเลย การบริหารจัดการ Project จึงเกิดขึ้นได้จาก Product Owner และ Team ซึ่งอาจจะมาจาก ผู้ใช้ตัวจริงในบริษัท หรือ มาจาก Product management แต่ไม่ใช่การบริหารงานโดย IT manager หรือ คนที่อยู่ในกลุ่ม Project Management Officer อย่างแน่นอน

Scrum ยังสามารถใช้งานได้กับงานที่ทำขึ้นมาครั้งเดียวแล้วจบ ไม่มีการรันต่อในระยะยาวอีกด้วย นั่นก็เพราะว่า Team และ Product Owner ทำงานส่วนของ Project management อยู่แล้ว

แล้วถ้าเกิดว่า งานที่มีขึ้นมาใหม่ สามารถทำได้เร็วจนเสร็จก่อนจบ sprint ทุกงานเป็นประจำอย่างต่อเนื่องเลยล่ะทำอย่างไรดี (แบบนี้จะเกิดขึ้นได้กับกรณีที่ทีมทำงาน 1 ทีม 1 sprint 1 project) ก็ควรจะลดเวลาใน sprint ให้สั้นลง เช่น เหลือ 1 สัปดาห์เป็นต้น

แต่บางครั้ง ก็อาจจะเกิดเหตุการณ์ที่งานใหม่ป้อนให้กับทีมไม่ทัน แบบนี้ Team จะต้องลองไปทำ application อื่นๆ ที่เกี่ยวข้องที่มีรอบ sprint ตรงกันบ้าง อย่างไรก็ดี ต้องระวังการทำแบบนี้ มันไม่ได้ทำให้เกิดประสิทธิผลในการทำงาน cross application กันเลย โดยปกติแล้ว แนวทางที่ทำให้เกิดประสิทธิภาพ ตามหลัก Scrum ก็คือ ทีม สามารถให้ความสำคัญ กับ product เดียว หรือ application เดียว ในแต่ละ Sprint

ความท้าทายที่จะได้เจอ

Scrum ไม่ใช่ชุดคำสั่งหรือแนวทางปฏิบัติที่ชัดเจน แต่ที่จริงแล้ว ความสำคัญของมันคือ framework ที่ทำให้เรามองเห็นโปร่งใส และกระบวนการที่ทำให้เกิด “inspect and adapt” หรือ การตรวจสอบ และ ปรับปรุง Scrum จะทำให้เราเห็นถึง ความผิดพลาด อุปสรรคที่จะมีผลกระทบต่อ Product Owner และ ประสิทธิภาพของ Team เช่น Product Owner จะไม่เห็นว่า ในตลาดเค้าไปกันถึงไหนแล้ว หรือ การที่ estimate business value ออกมาไม่ได้ หรือทีม ที่ไม่สามารถ ประเมินแรงงานที่ต้องใช้ หรือ ทักษะที่ต้องใช้ ในการทำงานก็ด้วยเช่นกัน

Scrum framework จะเผยจุดอ่อนเหล่านี้ออกมาให้เห็น Scrum ไม่ได้ช่วยแก้ปัญหาของการพัฒนาเลย แต่มันทำให้เผยปัญหาต่างๆออกมา และ มี framework เพื่อใช้บอกคนที่เกี่ยวข้องว่าจะหาทางแก้ปัญหาเหล่านั้น ในระยะเวลาอันสั้น แม้ว่าจะไม่มีประสบการณ์ในการแก้ปัญหาเลยก็ตาม

สมมุติว่า Team ผิดพลาดในการ deliver งานตามที่ได้ commit กันใน first sprint อันเนื่องมาจากไม่ได้วิเคราห์ และประเมินได้อย่างดีเพียงพอ ถ้าในมุมของทีม มันคือความผิดพลาด แต่ในชีวิตจริง มันคือประสบการณ์ที่ทำให้เราได้เรียนรู้ในการก้าวขั้นแรก เพื่อปรับเข้ามาสู่โลกความเป็นจริงมากขึ้น จากสิ่งที่เราได้ประเมินเอาไว้ ด้วยแนวทางนี้ scrum จะช่วยให้เผยปัญหาออกมา และให้ทีมได้เข้าไปแก้ปัญหามัน ซึ่งเป็นหลักการขั้นพื้นฐาน ที่สำคัญที่สุด สำหรับทีมที่เอา scrum ไปใช้งาน

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

ความผิดพลาดอีกอย่างหนึ่งก็คือ การหมดแรงและกำลังใจ หรือ เลิกทำ ก็เพราะว่ามีข้อผิดพลาดที่หาคำตอบไม่ได้จาก Scrum เยอะแยะไปหมด เช่น Scrum ไม่ต้องการให้ Product Owner กำหนดแผนกลยุทธ์ระยะยาวของ product ได้ หรือ การที่ให้ engineer ไปหาคำตอบจาก senior engineer ในการแก้ปัญหายากๆบางเรื่อง เหล่านี้ scrum ทิ้งเอาไว้ให้แต่ละคนเผชิญกันเอาเองเพื่อการตัดสินใจอย่างถูกต้อง แต่โดยส่วนใหญ่แล้ว จะสามารถแก้ไขได้ด้วยการปรึกษาจากคนที่รู้ และเชี่ยวชาญ

อีกสิ่งที่ต้องระวังก็คือ การบอกว่า Scrum เป็นเครื่องมือขั้นเทพ ที่จะช่วยเหลือทีมได้ เพราะจริงๆแล้ว Scrum บอกให้ทีมช่วยเหลือตัวเองต่างหากแถมยังไม่มีสูตรสำเร็จที่จะทำแล้วสำเร็จทันทีอีกด้วย การปรับใช้ที่ดีที่สุด อาจจะเริ่มต้นจากการให้ทีมได้เรียนรู้ก่อนว่า scrum คืออะไร จากแต่ละคนเอง หรือ จาก manager หรืออาจจะให้คนที่เชี่ยวชาญเข้ามาเล่าให้ฟังก็ได้ จากนั้นก็ให้ทีมเป็นคนตัดสินใจเองว่า จะทำหรือไม่ ถ้าทำก็กำหนด period ร่วมกัน แล้วเมื่อ จบ period นั้น ก็ให้ทีมได้ประเมินและตัดสินใจอีกครั้ง ว่าจะทำมันต่อหรือไม่

ความดีงามอีกอย่างก็คือในขณะที่เริ่ม first sprint นั้นจะเป็นความท้าทายของทีมมาก และข้อดี จาก scrum ก็คือ การเผยให้เห็นในตอนหลังๆจากหลายๆทีมที่ได้เริ่มทำ scrum ว่า “scrum มันยาก แต่ว่ามั่นใจได้ว่า ที่ทำไปทั้งหมด มันดีกว่าที่เราทำกันมาแบบเก่าแน่นอน”

จบแล้วสำหรับเนื้อหาจาก scrumprimer ทั้งหมด จากที่ผมได้อ่านจนจบแล้ว และมาแปลให้ได้อ่านกันอยู่ตรงนี้ ก็ทำให้ผมจากเดิมที่ไม่รู้เรื่อง scrum เลย และไม่รู้จะเริ่มต้นตรงไหนทำอย่างไร (ได้รับหน้าที่เป็น PO ในอภิมหา project มูลค่าเลข 8 หลัก) ก็รู้เรื่องมากขึ้น และเอามาปรับใช้ได้เลย หลายอย่างไม่สามารถปรับใช้ได้ตั้งแต่ sprint แรกแต่ก็ค่อยๆปรับปรุงกันไปเรื่อยๆ ค่อยๆใส่กิจกรรมเพิ่มขึ้นในแต่ละ sprint เพื่อให้ทีมก็ค่อยๆปรับตัวไป สำหรับคนที่ต้องการอ่านเรื่องทั้งหมดจาก scrumprimer ก็กดที่ tag ‘scrumprimer’ ด้านล่างได้เลยนะครับ