Agile Scaling: แนวทางปฏิบัติที่ดีที่สุดอย่างปลอดภัยสำหรับ Scrum Masters

บทความนี้เป็นส่วนที่สองของชุดการปรับขนาด Agile ของ Toptal ซึ่งออกแบบมาเพื่อแนะนำผู้จัดการโครงการในการขยายทีม อ่านงวดแรก “5 Agile Scaling Frameworks Compared: อันไหนที่คุณควรใช้?” สำหรับภาพรวมเชิงลึกของตัวเลือกยอดนิยม

เมื่อผลิตภัณฑ์เติบโตและซับซ้อนมากขึ้น ทีมที่ผลิตผลิตภัณฑ์ก็เช่นกัน เมื่อถึงเวลาต้องขยายขนาด หลายบริษัทเปลี่ยนจาก Scrum ไปเป็น Scaled Agile Framework (SAFe) ซึ่งเป็นระบบที่นำไปใช้ในระดับองค์กร และช่วยให้ธุรกิจต่างๆ สามารถจัดการผลิตภัณฑ์ที่ซับซ้อนหลายรายการซึ่งต้องใช้ทีมของทีมในการพัฒนา

Scrum master ที่ย้ายเข้าสู่เฟรมเวิร์ก SAFe จะเข้าสู่สภาพแวดล้อมที่คุ้นเคยและใหม่ทันที สิ่งประดิษฐ์ บทบาท และพิธีการต่าง ๆ อิงจาก Scrum แต่การทำงานในระดับที่สูงขึ้นนั้นมาพร้อมกับความรับผิดชอบเพิ่มเติมบางอย่างโดยเฉพาะอย่างยิ่งสำหรับผู้เชี่ยวชาญ Scrum ที่เลือกที่จะก้าวเข้าสู่บทบาทของวิศวกรระบบปล่อย (RTE) ซึ่งเป็นวิถีทั่วไป RTE ทำหน้าที่เป็น Scrum master ของรถไฟที่วางจำหน่ายทั้งหมด แทนที่จะนำทีม Scrum ที่มีสมาชิก 9 ถึง 11 คน RTE กลับกลายเป็นผู้นำคนรับใช้ให้กับทีมของทีมที่คร่อมหลายแผนก และจัดกิจกรรมที่มีขนาดและขอบเขตมากขึ้น

พื้นฐาน: Scrum to SAFe

SAFe ช่วยให้บริษัทสามารถนำแนวทาง ค่านิยม และหลักการของ Agile ไปใช้กับหลายทีมได้ ผลลัพธ์ที่ได้คือ "ทีมของทีม" เรียกว่า Agile release train (ART) แต่ละทีมยังคงจ้าง Scrum master เพื่อทำธุรกิจตามปกติ ในขณะที่บทบาทที่คล้ายกับ Scrum-master บน ART นั้นทำโดย RTE RTE ใช้กลไกทั่วไปและการกำกับดูแลของ Scrum แต่ในระดับองค์กร แทนที่จะเป็นทีม บทบาท Scrum ระดับทีมแบบดั้งเดิมและสิ่งประดิษฐ์อื่น ๆ จะเปลี่ยนแปลงไปตามนั้นเช่นกัน ตัวอย่างเช่น ART "เจ้าของผลิตภัณฑ์" กลายเป็นผู้จัดการผลิตภัณฑ์ "งานในมือของผลิตภัณฑ์" กลายเป็นงานในมือของโปรแกรม “sprint backlog” เป็นงานค้างแบบวนซ้ำ และตอนนี้ "การเพิ่มผลิตภัณฑ์" คือการเพิ่มโปรแกรม (PI)

มีการกำหนดค่า SAFe สี่แบบ—Essential, Large Solution, Portfolio และ Full—และการกำหนดค่าที่คุณใช้ขึ้นอยู่กับว่าบริษัทของคุณปรับใช้กรอบการทำงานมากน้อยเพียงใด การกำหนดค่าช่วยให้ใช้งานได้หลายระดับ ตั้งแต่หลายทีมทำงานร่วมกันไปจนถึงการรวมพอร์ตโฟลิโอทั้งหมดและความคล่องตัวทางธุรกิจทั่วทั้งองค์กร แต่ในทุกระดับ เป้าหมายยังคงเป็นการขยายขนาดการปฏิบัติ Agile และ Scrum ไม่ใช่แทนที่

Scrum Masters ใน SAFe

Scrum Master ที่ทำงานในเฟรมเวิร์ก SAFe ในระดับทีมจะพบว่างานของพวกเขาไม่แตกต่างกันอย่างมีนัยสำคัญ พวกเขาจะยังคงเป็นหัวหน้าคนรับใช้สำหรับทีม Agile รับผิดชอบการฝึกสอนและการศึกษา ขจัดสิ่งกีดขวาง และส่งเสริมสภาพแวดล้อมที่สมาชิกในทีมรู้สึกปลอดภัยที่จะดำเนินการอย่างดีที่สุดและปรับปรุงอย่างต่อเนื่อง

อย่างไรก็ตาม จะมีหน้าที่ใหม่บางอย่าง ต้นแบบ SAFe Scrum สนับสนุน RTE ในกิจกรรมการวางแผน PI และในการทำงานของโปรแกรม และเป็นตัวแทนของทีมในการประชุมการซิงค์ ART เมื่อมีสิ่งกีดขวางที่อยู่นอกเหนือความสามารถของทีมในการเอาออก ต้นแบบ Scrum จะส่งต่อไปยัง RTE

Scrum Master ที่ตัดสินใจเป็น RTE จะพบว่าบทบาทของพวกเขามาพร้อมกับข้อพิจารณาที่มากกว่าอย่างเห็นได้ชัด ART อาจรวมถึงทีมที่ใหม่สำหรับคุณหรือใหม่ต่อ Agile เช่น การวิเคราะห์ธุรกิจ ฮาร์ดแวร์ หรือการปฏิบัติตามข้อกำหนด และเนื่องจากการกำหนดค่าที่สูงขึ้นของ SAFe รวมถึงการทำงานของโปรแกรมหรือพอร์ตโฟลิโอ ฝ่ายบริหารจะมีส่วนร่วมโดยตรงและสม่ำเสมอในลักษณะที่จะไม่อยู่ใน Scrum เพื่อให้แน่ใจว่าทุกอย่างสอดคล้องกับเป้าหมายระดับองค์กรและ/หรือพอร์ตโฟลิโอ

RTE มีหน้าที่ในการขจัดสิ่งกีดขวางที่อยู่นอกเหนือความสามารถของทีมเดียว พวกเขาสื่อสารกับผู้มีส่วนได้ส่วนเสียและขับเคลื่อนการปรับปรุงอย่างต่อเนื่องในระดับ ART RTE โค้ชไม่เพียงแต่ทีมเท่านั้น แต่ยังเป็นผู้นำของทีมเหล่านั้นด้วย ช่วยให้ ART ทุกระดับก้าวไปสู่การจัดการตนเองและการจัดการตนเอง

SAFe Events

เช่นเดียวกับ Scrum master ที่อำนวยความสะดวกให้กับกิจกรรมระดับทีม RTE ก็อำนวยความสะดวกให้กับเหตุการณ์ระดับ ART—การวางแผน PI, การซิงค์ ART, การสาธิตระบบ และการตรวจสอบและดัดแปลง ในฐานะ RTE คุณจะมีส่วนร่วมกับผู้มีส่วนได้ส่วนเสียที่หลากหลายกว่าที่คุณเคยเป็น Scrum Master และจัดการทีมหลายทีมที่มีความสนใจที่แข่งขันกัน มีผู้เข้าร่วมมากกว่าและหลากหลายมากขึ้นในทุกงาน และคุณจำเป็นต้องจัดลำดับความสำคัญและรับการตอบรับจากความคิดริเริ่มล่วงหน้า

PI Planning

งานวางแผน PI เป็นพิธีสำคัญสำหรับ SAFe ซึ่งเป็นเซสชั่นขนาดยักษ์สองวันเพื่อกำหนดเป้าหมายของทุกทีมภายใน ART ในอีกแปดถึง 12 สัปดาห์ข้างหน้าโดยการสร้างแผน PI มันเหมือนกับเหตุการณ์การวางแผนการวิ่ง แต่ครอบคลุมหลายการวิ่งในหลายทีม

อินพุต

• วิสัยทัศน์ทางธุรกิจ
• รายการคุณสมบัติ 10 ถึง 15 อันดับแรกที่จะนำไปใช้
• รายละเอียดความจุของแต่ละทีม

ผลลัพธ์

• แผน PI (แผนการจัดส่งสำหรับการวิ่งห้าถึงหกครั้งถัดไป)
• วัตถุประสงค์ PI
• รายการความเสี่ยงที่อาจเกิดขึ้น

เคล็ดลับทั่วไปสำหรับเหตุการณ์การวางแผน PI

• รับซื้อผู้มีส่วนได้ส่วนเสีย ก่อนการประชุม RTE ควรกำหนดว่าใครคือผู้มีส่วนได้ส่วนเสียหลัก และแบ่งปันข้อมูลกับกลุ่ม
• จัดลำดับความสำคัญ ก่อนเซสชั่น ให้กำหนดเวลาการประชุมทั้งวันกับทีมจัดการผลิตภัณฑ์เพื่อตกลงในมุมมองระดับสูงว่าควรนำเสนอคุณลักษณะใด รวมถึงลำดับความสำคัญในอนาคต ในงานจะมีกิจกรรมมากมาย เช่น ความเสี่ยงและการพึ่งพาอาศัยกัน และเป็นการดีที่จะมีข้อตกลงทิศทางพื้นฐานไว้
• ซ้อม! การวางแผน PI เป็นงานใหญ่ อาจไม่เป็นประโยชน์ที่จะใช้เวลาสองวันเต็มในการฝึกซ้อม แต่เซสชั่นสองถึงสี่ชั่วโมงกับหัวหน้าทีมของ ART ที่สร้างประสบการณ์ที่ใกล้เคียงที่สุดเท่าที่จะเป็นไปได้จะช่วยได้อย่างมาก สร้างกำหนดการของงานในเวอร์ชันที่เข้าใจง่ายขึ้นแล้วแชร์ก่อนการฝึกซ้อม เพื่อให้การฝึกฝนสามารถเริ่มต้นจากสถานที่ที่มีข้อมูลครบถ้วน
• เตรียมพร้อมสำหรับภารกิจคืบคลาน เป้าหมายของการวางแผน PI คือการจัดทำแผนระยะยาวในระยะเวลาที่ค่อนข้างสั้น บางครั้งผู้คนอาจต้องการลงรายละเอียดอย่างละเอียดในทุกสิ่ง ซึ่งไม่ใช่จุดประสงค์ของงาน อธิบายเรื่องนี้กับหัวหน้าทีมในการซ้อมและในเซสชั่น เตือนทีมว่าเป้าหมายคือการส่งมอบแผนระดับสูงและสร้างแนวร่วม ไม่ใช่เพื่อวางแผนทุกนาทีในสามเดือนข้างหน้า
• เตรียมข้อมูลความจุของทีม ขอให้ผู้เชี่ยวชาญ Scrum ของคุณจัดเตรียมการคำนวณความจุสำหรับแปดถึง 12 สัปดาห์ข้างหน้า คาดหวังการตอบกลับหรือคำถาม ตัวอย่างเช่น Scrum Master อาจไม่ทราบแน่ชัดว่าทีมของพวกเขาจะขาดงานไปกี่ครั้งในช่วงสองเดือนข้างหน้า ในกรณีดังกล่าว ให้ขอค่าประมาณ และยืดหยุ่นเมื่อตอบสนองต่อขีดจำกัดความจุระหว่าง PI
• แบ่งปันวาระการวางแผน PI แจกจ่ายตารางเวลาอย่างน้อยสองสัปดาห์ก่อนงานและเตรียมพร้อมที่จะตอบคำถามมากมาย จะมีผู้เข้าร่วมประชุมจำนวนมาก และหาก SAFe ใหม่สำหรับคุณและบริษัทของคุณ ก็อาจเป็นเรื่องใหม่สำหรับสมาชิกในทีมคนอื่นๆ จากประสบการณ์ของผม เหตุการณ์การวางแผน PI ครั้งที่สองหรือครั้งที่สาม ความกดดันต่อผู้อำนวยความสะดวกจะรุนแรงน้อยลงเมื่อทีมคุ้นเคยกับเหตุการณ์และรู้ว่าจะเกิดอะไรขึ้น
• การเข้าร่วมประชุมผู้บริหารที่ปลอดภัย มักจะเป็นเรื่องยากสำหรับผู้จัดการหรือผู้จัดการอาวุโสที่จะเข้าร่วมงานสองวัน แต่การเข้าร่วมของฝ่ายบริหารเป็นสิ่งจำเป็นเพื่อให้แน่ใจว่ามีการจัดตำแหน่งในระดับสูง ยืนยันการเข้าร่วมอย่างน้อยสองสัปดาห์ก่อนการวางแผน PI และจัดเตรียมการสนับสนุนที่จำเป็น เช่นเดียวกับเจ้าของธุรกิจที่ต้องการลงนามในวัตถุประสงค์ของ PI

ART Sync

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

อินพุต

• ความก้าวหน้าของทีม
• บันทึกสิ่งกีดขวาง
• แผน PI (เพื่อระบุการเบี่ยงเบนที่สำคัญใดๆ ระหว่างแผนและความคืบหน้าจริง)

ผลลัพธ์

• การยกระดับ (ถ้าจำเป็น)
• การตัดสินใจเกี่ยวกับการเปลี่ยนแปลงแผน PI

เคล็ดลับทั่วไปสำหรับกิจกรรม ART Sync

• ส่งเสริมการสื่อสารอย่างสม่ำเสมอ เนื่องจาก ART Sync เป็นรายสัปดาห์ แทนที่จะเป็นรายวันเหมือน Scrum stand-ups RTE ควรทำให้ชัดเจนว่าทีมสามารถแจ้งปัญหาเร่งด่วนได้ทันที และไม่ควรรอการซิงค์ ART ครั้งถัดไป
• เตรียมข้อมูลให้พร้อม ขอให้ผู้เชี่ยวชาญ Scrum และเจ้าของผลิตภัณฑ์นำตัววัดความคืบหน้าเชิงปริมาณมาใช้ เช่น การหยุดทำงานหรือการไหลสะสม เพื่อที่จะได้มีข้อมูลการสนทนาเกี่ยวกับความคืบหน้า
• ไปไกลกว่าการตรวจสอบสถานะรายสัปดาห์ การซิงค์ ART มีขึ้นเพื่อเป็นเหตุการณ์ที่มีการจัดลำดับความสำคัญและปัญหาได้รับการแก้ไข ไม่ใช่การเช็คอินง่ายๆ

การสาธิตระบบ

การสาธิตระบบมีวัตถุประสงค์เพื่อแสดงขอบเขตทั้งหมดของงานที่สร้างขึ้นในระหว่างการทำซ้ำก่อนหน้านี้ ในงานนี้ ผู้จัดการผลิตภัณฑ์และทีมของพวกเขาจะแสดงให้เจ้าของธุรกิจและผู้มีส่วนได้ส่วนเสียอื่นเห็นถึงความคืบหน้าแบบบูรณาการของ ART ในรูปแบบปัจจุบัน

ป้อนข้อมูล

• สถานะปัจจุบันของงานโดยพิจารณาจากผลลัพธ์ของสมาชิกทีม Agile ทั้งหมดตลอดช่วงของการทำซ้ำก่อนหน้านี้

ผลลัพธ์

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

คำแนะนำทั่วไปสำหรับเหตุการณ์การสาธิตระบบ

• ซ้อม! อุทิศเวลา 30 ถึง 45 นาทีทุกสัปดาห์เพื่อทำงานร่วมกับผู้นำเสนอเพื่อแยกแยะส่วนของพวกเขา
• คลายสไลด์ นำเสนองานแบบบูรณาการที่เกิดขึ้นจริง หากคุณกำลังทำงานกับผลิตภัณฑ์ซอฟต์แวร์ ให้ผู้นำเสนอแสดงส่วนเพิ่มของผลิตภัณฑ์ที่ใช้งานได้แก่ผู้มีส่วนได้ส่วนเสีย แทนที่จะเป็นชุดสไลด์ ถ้าเป็นไปได้ สาธิตผลิตภัณฑ์ของคุณในสภาพแวดล้อมการแสดงละคร คุณต้องการให้การสาธิตคล้ายกับประสบการณ์ของผู้ใช้ปลายทางอย่างถูกต้อง หากคุณไม่สามารถนำเสนอระบบแบบบูรณาการได้ทุกๆ สองสัปดาห์ ให้ดูขั้นตอนการจัดส่งของคุณและระดมความคิดกับทีมเกี่ยวกับวิธีการนำวัฒนธรรม CI/CD และ DevOps มาใช้
• เน้นที่มูลค่าทางธุรกิจ การนำเสนอของคุณมีไว้สำหรับเจ้าของธุรกิจและผู้มีส่วนได้ส่วนเสีย แบ่งปันสิ่งที่สำคัญที่สุดสำหรับพวกเขา
• ให้ข้อเสนอแนะเน้น ความคิดเห็นของผู้มีส่วนได้ส่วนเสียที่คุณได้รับจะมีความสำคัญ แต่เหตุการณ์นี้ไม่ใช่เวลาสำหรับการเปลี่ยนแปลงอย่างมากต่อวิสัยทัศน์ของผลิตภัณฑ์หรือแผนงาน พร้อมที่จะนำการสนทนากลับไปสู่ข้อเสนอแนะระดับสูงที่ทีมสามารถเปลี่ยนเป็นรายการดำเนินการได้ในภายหลัง
• ให้มันสั้น ผู้มีส่วนได้ส่วนเสียเป็นคนยุ่ง การประชุม 45 ถึง 60 นาทีจะส่งผลให้มีผู้เข้าร่วมประชุมบ่อยและมีส่วนร่วมมากขึ้น
• ให้เวลากับคำถามและคำตอบ โปร่งใสในคำตอบของคุณ จำไว้ว่าบางครั้ง “ฉันไม่รู้ แต่เราหาได้” เป็นคำตอบที่ดีที่สุด

ตรวจสอบและปรับตัว

การตรวจสอบและดัดแปลงเป็นเซสชันย้อนหลังครั้งใหญ่ที่เกิดขึ้นเมื่อสิ้นสุด PI เซสชั่นแบ่งออกเป็นสามส่วน,

• การสาธิตระบบ PI: การแสดงสำหรับเอาต์พุตรวมของ PI ทั้งหมด คล้ายกับการสาธิตระบบหลัก แต่แทนที่จะทำซ้ำหนึ่งครั้ง เหตุการณ์นี้จะแสดงงานแบบบูรณาการใน PI ทั้งหมด
• การวัดเชิงปริมาณและเชิงคุณภาพ: โอกาสสำหรับ RTE ในการนำเสนอเมตริกที่รวบรวมตลอดหลักสูตร PI เมตริกเหล่านี้รวมถึง (แต่ไม่จำกัดเพียง) ความเร็วของทีม เรื่องราวของผู้ใช้ที่ยอมรับ ความครอบคลุมในการทดสอบหน่วย หรือข้อบกพร่องที่เปิดอยู่
• การประชุมเชิงปฏิบัติการย้อนหลังและการแก้ปัญหา: โอกาสสำหรับผู้เข้าร่วมในการมองย้อนกลับไปที่ PI ไตร่ตรองถึงสิ่งที่ได้และไม่ได้ผล ระบุปัญหาที่เป็นระบบ และเสนอวิธีการแก้ไข

อินพุต

• ความก้าวหน้าของทีม
• สถานะปัจจุบันของงานรวมของ ART รวมถึงเอาต์พุตของโปรแกรมที่เพิ่มขึ้นทั้งหมด

เอาท์พุต

• รายการการปรับปรุงที่อาจเกิดขึ้น

เคล็ดลับทั่วไปในการตรวจสอบและปรับเปลี่ยนเหตุการณ์

• แจ้งให้เจ้าของธุรกิจทราบล่วงหน้า แจ้งล่วงหน้าอย่างน้อยสองสัปดาห์ก่อนงาน พบกับผู้จัดการผลิตภัณฑ์และเจ้าของธุรกิจที่เข้าร่วมก่อนเซสชั่นเพื่อนำเสนอผลลัพธ์เชิงคุณภาพ
• รักษาความปลอดภัยการเข้าร่วมของผู้มีส่วนได้ส่วนเสียอาวุโส การปรากฏตัวของพวกเขาเป็นสิ่งสำคัญที่สุดในการสาธิตระบบ PI เมื่อคุณแสดงผลงานของทีมและผลิตภัณฑ์ที่กำลังพัฒนา ตัวชี้จำนวนมากสำหรับการสาธิตระบบปกติใช้ที่นี่: ฝึกซ้อมล่วงหน้า หลีกเลี่ยงสไลด์การนำเสนอ และแสดงสิ่งที่ส่งมอบจริง
• หลีกเลี่ยงการตำหนิ ตลอดเซสชั่น ตรวจสอบให้แน่ใจว่าไม่มีใครรู้สึกว่าถูกคุกคามโดยข้อมูลที่นำเสนอหรือปัญหาที่ระบุในการหวนกลับ บางทีมอาจรู้สึกอิจฉาหรือตั้งรับหากทีมอื่นมีแต้มสูงกว่า หรือรู้สึกว่าถูกแยกออกมาหากเกิดปัญหาขึ้นกับทีมของตน ยอมรับวัฒนธรรมทั้งทีมเพื่อขจัดปัญหาดังกล่าว
• เน้นประเด็นที่เป็นระบบ พยายามอย่าให้ความสนใจกับปัญหาที่เกิดขึ้นเป็นระยะๆ มากเกินไป ให้พื้นที่สำหรับระดมความคิดแก่ทีมของคุณ และปล่อยให้จินตนาการเป็นอิสระสำหรับวิธีแก้ปัญหาที่เสนอ
• สร้างข้อเสนอที่สามารถดำเนินการได้ เมื่อสิ้นสุดกิจกรรม คุณควรมีรายการงานในมือให้ทีมดำเนินการ การระบุปัญหาไม่ได้ช่วยอะไรถ้าคุณไม่ทำตามขั้นตอนเพื่อแก้ไขปัญหา

ตารางด้านล่างเปรียบเทียบเหตุการณ์ SAFe กับสิ่งที่เทียบเท่ากับ Scrum และอธิบายความถี่และการดำเนินการของพิธีการในระดับองค์กร:

ก้าวขึ้นและขยายขึ้น

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