LeSS Framework ในมุมมองของ Scrum Master ตอนที่ 2
สวัสดีครับทุกคน วันนี้จะมาบอกเล่าปรสบการณ์ ต่อจากตอนที่ 1 ในการที่ได้มีโอกาสไปเข้าร่วมการ เทรนนิ่ง LeSS Framework และในตอนที่ 2 ผมจะมาเล่าให้ฟังว่าในเวลาทั้งหมดสามวัน เราได้รับอะไรจาก คอร์สนี้
DAY 1
เริ่มกันตรงเวลาที่ 9.00 ในช่วงแรกของวันนี้ ทางคุณ Bas ได้ทำการ ปรับความเข้าใจเกี่ยวกับ LeSS ให้กับทางนักเรียนทุกคน ได้เห็นภาพของ LeSS ในมุมมองและความเข้าใจที่ตรงกัน ทางคุณ Bas ได้ใช้วิธีการ ยกตัวอยาก การเข้าไป Adoption LeSS Framework ให้กับทาง องค์กรต่างๆ โดนจะเน้นไปที่ปัญหาต่างๆ และวิธีการทำความเข้าใจ กับทาง ผู้บริหารขององค์กร ก่อนเป็นอันดับแรก จากนั้นก็อธิบายเรื่องของ LeSS Rules อันนี้สำคัญมากๆ เพราะว่า LeSS Rules จะทำหน้าที่คลายกับ Scrum Guide ที่จะเป็นตัวกำหนดให้การ Adoption สามรถทำได้ถูกต้องตามที่ Creater ตั้งใจไว้
สนใจเข้าไปศึกษาเพิ่มเติมได้ที่นี่เลยครับ -> https://less.works/less/rules
Systems Thinking — เป็นวิธีการ ที่ทางคุณ Bas แนะนำให้กับทางทีมเป็น Framework ที่จะให้ทีมช่วยมองถึงปัญหา ต่างๆที่เกิดขึ้นว่า จริงๆแล้ว ต้นตอ ของปัญหาคืออะไรและ ทางแก้ไขที่ดีคืออะไร
LeSS <> Scaling Scrum Team
ข้อนี้ ในมุมมองของผม สำคัญสุดๆ เพราะก่อนที่จะได้มาเข้าเทรนนิ่ง ทางผมเองก็ได้มีการศึกษาเกี่ยวกับ LeSS มาก่อนแล้วในระดับหนึ่ง แต่พอได้เข้ามาเรียนรู้กับทาง คุณ Bas จริงๆจังๆ เลยได้เข้าใจว่า สิ่งที่ผมเห็นภาพจากการที่ศึกษาด้วยเองกับการที่ได้มาเรียนรู้จาก ต้นฉบับ มันเป็นคนละเรี่องกันเลย โดยที่ก่อนหน้านี้ผมจะมองว่า LeSS คือวิธีการที่เราจะทำการ Scaling Scrum Team ของเราให้ มีจำนวนมากขึ้นเพื่อ Support กับขนาดของ Product ที่โตขึ้น แต่จริงๆแล้ว ไม่ใช่เลย LeSS เล่นใหญ่กว่านั้นไปไกลมาก เพราะเค้ามองระดับว่าเป็นการเปลี่ยนการทำงานของ ระดับองค์กร และ มุมมองในการมองตัว Product ที่ทำไม่ได้มองจากทีมหรือว่า ตัว Platfrom แต่มองมาจากมุมมอง ของ Customers เลย ดังนั้นการที่เราจะทำการ Adoption LeSS ให้กับทางองค์กรของเรานั้น มันเป็นเรื่องที่ค่อนข้างที่จะใหญ่มาก และ มีผลกระทบและการทำงานกับคนหลายส่วนเลย ทางคุณ Bas เลยย้ำกับนักเรียนทุกคน ว่าการที่จะ Adoption LeSS Freamwork ให้ประสบความสำเร็จได้นั้น ควรจะเร่ิมที่ปรับความเข้าจากระดับ Management level ก่อนควรให้มีการยอมรับและสั่งการลงมาจากระดับบนลงล่างจะดีที่สุด
การได้รับการสนับสนุนจาก Management เป็นสิ่งที่สำคัญที่สุดในการที่จะทำการเปลี่ยนแปลงขบวนการทำงานขององค์กร และขับเคลื่องการทำ Agile Transformation ให้สำเร็จ
DAY 2
เริ่มต้นกัน ตรงเวลาเหมือนเดิม 9.00 วันนี้ทางคุณ Bas ได้เริ่มจะเจาะลึกเรื่องของ LeSS Team Structure และ Role ต่างๆ ที่มีอยู่ในทีม และ LeSS Huge (OMG นอกจาก LeSS แล้วยังมี LeSS Huge อีก ห้าๆๆๆๆๆ )
Product Owner ใน LeSS ทางคุณ Bas ได้เน้นย้ำเกี่ยวกับ Role นี้เยอะมาก เรียกได้ว่าแทบจะเป็นหัวใจสำคัญของ LeSS เลย โดยที่ทาง LeSS ได้กำหนดว่า ควรจะมี PO แค่ 1 คน 1 Prodcut Backlog เท่านั้น ย้ำว่า แค่ 1 คนเท่านั้น !!!!!
แต่ถ้า Prodcut ที่เราทำนั้นมีขนาดใหญ่และมีทีมที่จะต้อง Develop ตั้งแต่ 8 ทีมขึ้นไปคุณ Bas แนะนำให้ใช้เป็น LeSS Huge
โดยที่ LeSS Huge จะแนะนำให้มี APO (Area Product Owner)เพิ่มเติมขึ้นมาเพื่อช่วยในเรื่องของการลง Detail ต่างๆในตัวของ Product Backlog Item
ส่วนเรื่องรายละเอียดในการทำงานร่วมกันทีม ก็จะคลายๆกับทาง Scrum ในรูปแบบปรกติ แต่จะมีรายละเอียดเล็กๆน้อยๆ ที่แต่ต่างกันออกไป
Product Developers (Engineers)
ในหัวข้อนี้ เป็นหัวข้อที่ค่อนข้าง สนุกมากๆ ในความรู้สึกของผมเพราะว่า คนที่มาเข้าร่วมในครั้งนี้ ส่วนใหญ่จะเป็น ประชากร Developers เกินกว่าครึ่ง ฉะนั้นในหัวข้อนี้ จึงเต็มไปด้วยการ ถาม-ตอบ กันตลอดเวลา แต่สรุปคร่าวๆได้ว่า
ทีม Engineers ควรเป็น Feature Teams มากกว่าจะเป็น Component Teams
และอีกหัวข้อหนึ่ง ที่น่าสนใจในวันนี้คือ การทำ PBR — Product Backlog Refinement(User Story Grooming) และ Multi-Team Sprint Planning II หรือในทีม Scrum เราอาจจะเรียกว่า Dev Planning หรือว่า Sprint Planning part II
PBR — มีจุดที่น่าสนใจคือ โดยปรกติที่เราทำกันอยู่คือ ให้ทาง PO เป็นคนที่อธิบายตัวเนื้อหาของ PBIs และ ให้ทางทีม Developers ได้ทำการซักถามข้อสงสัยต่างๆกับทาง PO และจะมี SM เป็นคนค่อยที่จะ Facilitator ให้เป็นแบบ 1 PO : 1 Developer Team แต่ในแบบของ LeSS เราจะมีการ Mixed team members กันระหว่างทีม เช่น หากใน Product team เรามี Product developers 3 ทีม ก็ให้นำ สมาชิกของทั้งสามทีมมาทำการ Mixed กันใหม่ให้ออกมาเป็น 3 ทีม เท่าเดิมและทำการส่งตัวแทนทีมไปเลือก PBIs กลับมาที่ทีมเพื่อเอามาทำการ Refinement โดยที่แต่ละทีมจะทำความเข้าใจตัว PBIs กันเองไปพร้อมๆกัน โดยที่ถ้าหากมีส่วนไหนที่ต้องการข้อมูลเพิ่มเติมหรือว่ามีข้อสงสัย ก็จะทำการ สอบสามกับ PO ที่รออยู่ที่กลางห้อง หรือว่าถ้ามี PBI ตัวไหนที่ต้องไปเกี่ยวข้องกับอีกใบหนึ่ง ที่ทีมอื่นทำการ Refinement อยู่ ทีมก็จะต้องเดินไป พูดคุยสอบถามกันทันที หลังจากที่ ทุกทีมทำการ Refinement เสร็จเรียบร้อยแล้ว Developers ก็จะกลับเข้าทีมของตัวเองตามปรกติ อ่านมาถึงตรงนี้น่าจะมีข้อสงสัยและความงงกับวิธีการนี้แน่ๆ เพราะผมเองก็รู้สึกงงตอนที่ได้ยินวิธีการนี้ครั้งแรก แต่พอได้ยินทาง Bas ตอบคำถามต่างๆ ในห้องเรียนผมก็รู้สึกว่า เทคนิคนี้น่าสนใจมากๆ และโดยส่วนตัวคิดว่าน่าจะนำกลับมาปรับใช้กับทีมแน่นอน ข้อดีที่เห็นเลยคือ PO สามารถ ทำ PBR พร้อมกันกับทาง Developers ทุกทีม มันใจว่าจะใช้เวลาน้อยลงแน่นอน แต่เท่าที่ดูคือ ถ้า User Story มีขนาดที่ไม่พอดี หรือว่ายังมีข้อมูลที่ไม่ใช้เจน อาจจะทำให้เสียเวลามากขึ้นไปอีก
Sprint Planning II — ทางคุณ Bas เองเลือกที่จะใช้เทคนิคคล้ายคลึงกับตอนที่ทำ PBR แต่ว่าจะไม่มีการ Mixed team members แล้ว แต่ยังเลือกที่จะให้ทุกทีมอยู่รวมกันในห้อง และ ถ้าหากในแต่ละทีมมีข้อสงสัยหรือว่ายังไม่เข้าใจในเงื่อนไขที่ทาง PO เขียนใน User Story ก็สามารถถาม PO หรือว่า ทีมอื่นที่เกี่ยวข้องเพิ่มเติมได้เลย สรุปว่าทางคุณ Bas ก็ยังสนับสนุนให้ทีม มี Synchronous Dependencies กันเยอะๆ ระหว่างทีม
ซึ่งเรื่องนี้ก็เป็น หัวข้อที่ทางคุณ Bas ได้ทำการยกไปพูดคุยในงาน Agile Bangkok 2022 ที่ใช้ชื่อว่า “Maximizing Dependencies with Interdependent Teams”
และในวันที่สอง ก็จะจบเนื้อหาอยู่ที่เรื่องกระบวนทำงานของทางทีม Product Developers และ การตอบข้อสงสัยให้กับนักเรียนเยอะมากๆ ซึ่งในมุมมองส่วนตัวของผม รู้สึกชอบกับการเทรนนิ่งแบบนี้มาก
ในบทความต่อไปผมจะขอเล่าประสบการณ์ของวันสุดท้าย และ บทสรุปจากมุมมองของผมที่มีต่อการได้เข้าไปเทรนนิ่งในครั้งนี้
ปล. จริงๆเนื้อหาของการเรียนในแต่ละวันเยอะมากๆ ละเอียกกว่าที่ผมนำมาเขียนให้อ่านอีกครับ แต่ผมอยากที่จะเสนอในมุมมองที่ผมเห็นว่าเป็นจุดที่สำคัญและแปลกใหม่
