กรณีศึกษาที่ปลอดภัย: บันทึกการเปลี่ยนแปลงจากภาคสนาม

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

รายงาน Agile ประจำปีครั้งที่ 15 ระบุว่า บริษัท 94% ได้ฝึกฝนความคล่องตัวในบางรูปแบบ แต่การวิจัยยังชี้ให้เห็นว่า 90% ขององค์กรมีปัญหากับการใช้งาน Agile ทั่วทั้งองค์กร โดยปกติแล้ว เป็นงานของโค้ช Agile, Scrum master และผู้เชี่ยวชาญด้านการจัดการโครงการอื่นๆ ที่จะเป็นผู้นำและจัดระเบียบความพยายามเหล่านี้ บ่อยครั้ง พวกเขากำลังทำงานกับทีมหรือแผนกที่ต่อต้านการเปลี่ยนแปลง ในวัฒนธรรมของบริษัทที่เข้าใจยาก

ในโต๊ะกลมนี้ ผู้จัดการโครงการ Toptal สามคนพูดคุยถึงความท้าทายของการเป็นผู้นำการเปลี่ยนแปลงแบบ Agile เนื่องจากโซลูชันของพวกเขาสอดคล้องกับ Scaled Agile Framework (SAFe) เราจึงได้พูดคุยกับ Dean Leffingwell ผู้สร้าง SAFe ข้อมูลเชิงลึกโดยรวมของพวกเขาแสดงให้เห็นถึงความจำเป็นที่ผู้ปฏิบัติงาน SAFe ต้องเตรียมวิสัยทัศน์ที่ชัดเจนว่าความคล่องตัวคืออะไรและแผนความเป็นผู้นำที่สามารถนำทีมที่ดื้อรั้นเข้ามามีส่วนร่วมได้

พูดคุยอย่างปลอดภัยกับผู้สร้างกรอบงาน

SAFe ซึ่งเป็นกรอบการทำงานที่เป็นทางการโดย Scaled Agile ซึ่งมีอายุย้อนไปถึงปี 2014 เท่านั้น แต่สำหรับ Leffingwell งานนี้เริ่มต้นขึ้นเมื่อเขาพบกับทีม Agile เป็นครั้งแรกในช่วงต้นทศวรรษ 2000 ในฐานะนักระเบียบวิธีการพัฒนาซอฟต์แวร์ เขาประทับใจกับผลลัพธ์ของแนวทางปฏิบัติแบบ Agile ในทีมนักพัฒนา และเขาก็เริ่มสำรวจทันทีว่าจะนำ Mindset ไปใช้กับทั้งบริษัทได้อย่างไร ถ้าทีม Agile สามารถสร้างผลงานได้ ทีมของ Agile ที่ร่วมมือกันจะสร้างอะไรได้บ้าง? แนวทางปฏิบัติแบบ Agile สามารถนำมาใช้กับโครงการการเปลี่ยนแปลงเต็มรูปแบบในบริษัทระดับประเทศหรือระดับนานาชาติได้อย่างไร ดังที่ Leffingwell กล่าวไว้ “ฉันชอบการพัฒนาซอฟต์แวร์ ฉันรักเปรียว ฉันแค่ต้องการมัน ใหญ่ ”

ในช่วงหลายปีที่ผ่านมา บริษัทต่างๆ ได้ตระหนักถึงประโยชน์ของ SAFe ซึ่งรวมถึงการส่งมอบที่สั้นลง คุณภาพผลิตภัณฑ์ที่สูงขึ้น ประสิทธิภาพที่มากขึ้น และพนักงานที่มีส่วนร่วมมากขึ้น ในปี 2564 องค์กรมากกว่าหนึ่งในสามทั่วโลกใช้ SAFe และในแง่มุมที่สำคัญที่สุดคือกระบวนการที่ใช้ร่วมกันและภาษาที่เป็นหนึ่งเดียวที่ให้บริการ ตัวอย่างเช่น หากทีมหนึ่งคิดว่าการวิ่งระยะสั้นมีระยะเวลาสองสัปดาห์ และอีกทีมหนึ่งคิดว่ามันใช้เวลา 30 วัน ก็จะสร้างสิ่งที่ Leffingwell อธิบายว่าเป็น “ปัญหาหอคอยแห่ง Babel” เป็นเรื่องยากสำหรับทีมที่จะพูดคุยถึงคุณลักษณะที่จะเพิ่มหากพวกเขาไม่สามารถตกลงกันได้ว่า "คุณลักษณะ" หมายถึงอะไร “คุณต้องการ [ต้องการ] คนที่ทำงานในลักษณะเดียวกัน ถ้าคุณต้องการสร้างโซลูชันขนาดใหญ่” เขากล่าว “ไม่มีคำใดในอุตสาหกรรมของเราที่ไม่มีการโอเวอร์โหลด เช่น 'การทำซ้ำ' หรือ 'sprint' หรือ 'backlog' มันไม่มีประโยชน์หากคุณพยายามทำงานข้ามทีมและข้ามเขตแดน”

เรื่องราวความสำเร็จที่คล่องตัว

การให้ทุกคนในบริษัทนำวิธีการพูดและการทำงานที่เป็นหนึ่งเดียวกันมาใช้เป็นงานที่น่ากลัว แม้ว่าจะมีความเร่งด่วนอย่างมากสำหรับการเปลี่ยนแปลงก็ตาม ในบริษัทที่จัดตั้งขึ้น มันอาจจะยากขึ้น Leffingwell อธิบายเพิ่มเติมว่า: “คุณกำลังดูบริษัทที่ใหญ่ที่สุดในโลกที่ทำเงินได้มากมายและทำได้ดีอย่างเหลือเชื่อและแข่งขันกัน—และพวกเขาต้องเปลี่ยนแปลง คำถามสำหรับพวกเขาคือทำไมพวกเขาถึงควร” ผู้จัดการโปรเจ็กต์ Toptal ให้ความสำคัญที่นี่ แต่ละคนพบคำถามเช่นนี้ระหว่างกิจกรรมการปรับขนาดของตนเอง และแต่ละคนก็พบวิธีการทำงานของตนเองผ่านการเปลี่ยนแปลงแบบ Agile โดยใช้ SAFe

แสดงให้เห็นถึงคุณค่า

Alvaro Villena ผู้จัดการโครงการ Toptal ในเมืองซานติอาโก ประเทศชิลี เพิ่งเสร็จสิ้นการเปลี่ยนผ่าน SAFe สำหรับพอร์ตโฟลิโอที่พัฒนาแพลตฟอร์มข้ามธุรกิจ "ก้าวแรกในการเปลี่ยนแปลงของฉันคือการจัดเวิร์กช็อปสตรีมคุณค่า" เขากล่าว พูดง่ายๆ ก็คือ เวิร์กชอปสตรีมคุณค่าคือการประชุมเริ่มต้นเพื่อระบุกระบวนการทางธุรกิจทั้งหมดตั้งแต่แนวคิดไปจนถึงการส่งมอบ และขั้นตอน ผู้ใช้ ระบบ และจุดปวดในระหว่างทั้งหมด

การให้ตัวแทนจากทั้งองค์กรเข้าร่วมการประชุมเชิงปฏิบัติการช่วยให้ Villena เข้าใจวัฒนธรรมของบริษัทและอุปสรรคของเขาจะเป็นอย่างไร “ก่อนที่เราจะใช้เวิร์กช็อป มีโครงสร้างที่ธุรกิจหนึ่งมีทีม อีกธุรกิจหนึ่งมีทีม และธุรกิจถัดไปมีทีม - ทั้งสามไม่ได้พูดคุยกัน”

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

“ไม่มีใครต้องการการเปลี่ยนแปลงจนกว่าพวกเขาจะรู้ว่าทำไม ดังนั้นคุณเริ่มต้นด้วยเหตุผลและให้อนาคตที่ดีกว่าแก่พวกเขา” Dean Leffingwell ผู้สร้าง SAFe

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

แม้ว่าทุกคนจะกระตือรือร้นบนเรือ คุณก็ยังควรคาดหวังการเริ่มต้นที่หนักหน่วง ตัวอย่างเช่น ทีมที่คุ้นเคยกับการพัฒนา Waterfall แบบดั้งเดิมและการเปิดตัวครั้งใหญ่ อาจมีปัญหาในการย้ายไปใช้กระบวนการพัฒนาซ้ำๆ และคล่องตัวมากขึ้น แม้ว่าพวกเขาจะเห็นคุณค่าในนั้นก็ตาม “การเพิ่มโปรแกรมครั้งแรกที่เราทำนั้นเป็นหายนะกับทีม” Villena กล่าว “และเรารู้ว่ามันจะเป็น; เราบอกลูกค้าให้คาดหวังว่าสามเดือนแรกอาจเป็นเรื่องยาก” เพื่อชดเชยสิ่งนี้ เขาสร้างการวนซ้ำเป็นเวลา 1 สัปดาห์เมื่อสิ้นสุดการเพิ่มโปรแกรมแรก (PI) ซึ่งทีมสามารถประเมินความก้าวหน้าของพวกเขาได้ เขาจัดให้มีการวิ่งที่ทุ่มเทให้กับการปรับปรุงกระบวนการและการประเมินเท่านั้นที่จะไปไกลกว่าการตรวจสอบและปรับตัวตามปกติ เขาพบว่าการปรับใช้กรอบความคิดแบบ Agile ไม่เพียงแต่กับผลิตภัณฑ์เท่านั้น แต่ยังรวมถึงการเปลี่ยนแปลงทางธุรกิจด้วย โดยใช้เวลาในการถอยกลับ ดูว่าสิ่งใดใช้ได้ผลและสิ่งใดไม่ได้ผล และปรับเปลี่ยนตามนั้น

สร้างชัยชนะเล็กๆ

สิ่งสำคัญคือต้องเตรียมพร้อมสำหรับอุปสรรคที่ไม่คาดคิดในการปรับใช้ SAFe ของคุณ เมื่อหลายปีก่อน Miroslav Anicin ผู้จัดการโครงการของ Toptal ในเมืองเบลเกรด ประเทศเซอร์เบีย กำลังเปลี่ยนบริษัทโทรคมนาคมเป็น SAFe บริษัทได้ว่าจ้างบริษัทภายนอกในการพัฒนาซอฟต์แวร์ทั้งหมด การรวมทีมนอกสถานที่ไม่ใช่งานที่ยุ่งยากนัก ปัญหาที่เกี่ยวข้องส่วนใหญ่เป็นงานด้านลอจิสติกส์ แต่ความพยายามสร้างความท้าทายที่คาดไม่ถึงในการเปลี่ยนบริษัทเอง “ฉันกำลังค้นหาความสามารถที่เราต้องการในขบวนการปล่อยตัว” เขากล่าว “และทุกคนที่ฉันต้องเลือกมาจากการตลาด จากทางกฎหมาย จากผลิตภัณฑ์ จากการเงิน—ขาดแนวความคิดแบบ Agile หรือแม้แต่ประสบการณ์ใน Agile โดยสิ้นเชิง”

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

การย้ายไปสู่การตัดสินใจแบบกระจายศูนย์มากขึ้นนั้นต้องการ “การเปลี่ยนวิธีการทำงานจากคำสั่งและการควบคุม ผ่านความเป็นผู้นำของผู้รับใช้ ไปสู่วัฒนธรรมการเรียนรู้และวัฒนธรรมของ Agile ที่เสริมพลัง—และความสามารถในการทนต่อความผิดพลาด” Leffingwell กล่าว

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

ตอบสนองความต้องการของทีมของคุณ

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

วิธีแก้ปัญหาของ SAFe สำหรับปัญหานี้สามารถพบได้ในแบบจำลองงานที่สั้นที่สุดที่ถ่วงน้ำหนักก่อน (WSJF) WSJF กำหนดมาตรฐานสำหรับการจัดลำดับความสำคัญของงาน ดังนั้นเมื่อถึงเวลาต้องตัดสินใจว่างานต่อไปควรเป็นอย่างไร ขั้นตอนแรกจะไม่เกี่ยวข้องกับการโต้เถียงกันว่าจะจัดลำดับความสำคัญอย่างไร ในระบบ Agile แบบ Flow-based คุณไม่ต้องกังวลกับการส่งมอบทุกอย่างในคราวเดียว เพราะอย่างที่ Leffingwell กล่าวว่า "สิ่งสำคัญที่สุดคืองานที่จะทำต่อไป และนั่นเป็นคำถามที่ตอบง่ายกว่างานที่มีค่าที่สุด” SAFe มอบวิธีการแก้ไขการพึ่งพาระหว่างทีม—งานสั่งงานมีความสำคัญต่อผลลัพธ์นี้

เส้นทางสู่การแก้ปัญหาการพึ่งพาของ Marouane นั้นไม่แน่นอน: “หลังจากวิ่งสองครั้ง ก่อนการตรวจสอบและปรับตัวครั้งแรก เราสังเกตเห็นว่าบางทีมไม่ปฏิบัติตามแผน PI ของเรา” การขึ้นต่อกันที่กำหนดไว้ในแผน PI ไม่ได้รับการปฏิบัติตาม ดังนั้นงานของทีมหนึ่งจึงไม่สามารถเริ่มต้นได้เนื่องจากการสนับสนุนจากทีมอื่นไม่พร้อม

“เนื่องจากเป็นการทำซ้ำครั้งแรก และทีมงานไม่คุ้นเคยกับงานประเภทนี้ เราจึงตัดสินใจที่จะจัดพิธีพิเศษขึ้น ซึ่งเป็นการประชุมประจำสัปดาห์เพื่อหารือเกี่ยวกับความคืบหน้าในการพึ่งพาอาศัยกัน” Marouane กล่าว “บุคคลหนึ่งจากแต่ละทีมมาเพื่ออัปเดตความคืบหน้าเกี่ยวกับผลงานของพวกเขา” ด้วยวิธีนี้ หากทีม A กล่าวว่าพวกเขาไม่สามารถส่งมอบได้ ทีม B สามารถรู้ล่วงหน้าและวางแผนตามนั้นได้ แทนที่จะรอความช่วยเหลือที่จะไม่เกิดขึ้นจริงในช่วงเริ่มต้นของการวิ่ง

Leffingwell เตือนสติเมื่อทำการปรับเปลี่ยน SAFe ประเภทนี้: “SAFe เป็นระบบความรับผิดชอบ … คุณสามารถปรับตัวได้ แต่คุณต้องระวังให้มาก” แม้ว่าเฟรมเวิร์กนี้ตั้งใจให้ปรับเปลี่ยนได้ แต่การเปลี่ยนแปลงมักจะถูกหลอมรวมเข้าไปหากไม่ได้ทำการประเมินใหม่ มีการกำหนดค่า Essential SAFe เพื่อให้แน่ใจว่าการเปลี่ยนแปลงใดๆ เป็นไปตามเกณฑ์พื้นฐาน

พิธีพิเศษของ Marouane ถูกรวมอีกครั้งใน PI ที่สอง และในครั้งที่สามก็ถูกยุติลง ทีมไม่มีอะไรจะรายงานเกี่ยวกับที่ยังไม่ได้รับการสื่อสาร ความยืดหยุ่นที่เพิ่มขึ้นเล็กน้อยทำให้ Marouane นำทีมกลับเข้าสู่กระบวนการแบบเดิมๆ เธอพบว่าการเปลี่ยนผ่านนั้นจำเป็นต้องมีกรอบความคิดแบบ Agile เพื่อให้ได้ประโยชน์สูงสุดจากทีมของสถาบันการเงิน และที่สำคัญ การเปลี่ยนแปลงที่เธอทำผ่านความมุ่งมั่นในการปรับปรุงอย่างต่อเนื่อง ในที่สุดก็ได้ใช้หลักการ Lean-Agile ซึ่งเป็นรากฐานของ Essential SAFe โซลูชันของเธอทำให้บริษัทมีวิสัยทัศน์ที่เป็นหนึ่งเดียวที่บริษัทขาดไป และช่วยให้ทีมทำงานร่วมกันในลำดับความสำคัญเดียวกันได้

ปรับตัวเพื่ออนาคต

กรอบการทำงานใด ๆ ที่ทำงานในวงกว้างจะมาพร้อมกับความท้าทาย จำนวนชิ้นส่วนที่เคลื่อนไหวและความสนใจที่แข่งขันกันมีมากมาย แต่ผลตอบแทนก็มากเท่ากัน และการเปลี่ยนแปลงที่มีการดำเนินการอย่างดีจะช่วยให้ทีมมีเครื่องมือที่จำเป็นในการทำงานเพื่อไปสู่เป้าหมายร่วมกัน อุปสรรคที่คุณเผชิญในการนำไปใช้ในวงกว้างนั้นไม่อาจคาดเดาได้ และแนวความคิดแบบ Agile ช่วยให้ Villena, Anicin และ Marouane ปรับตัวเข้ากับความท้าทายที่ไม่คาดคิด ท้ายที่สุด นั่นคือสิ่งที่ต้องนำเสนออย่างต่อเนื่อง: เสริมศักยภาพกระบวนการของคุณด้วยเครื่องมือเพื่อปรับให้เข้ากับสิ่งที่ไม่คาดฝัน

Scaled Agile ยังปรับให้เข้ากับเทคโนโลยีใหม่และมาตรฐานอุตสาหกรรมที่กำลังพัฒนา โดยแนะนำเครื่องมือและความสามารถใหม่ๆ ตามความจำเป็น ทุกคนต้องมีความว่องไวและเตรียมพร้อมสำหรับสิ่งที่ไม่คาดคิด “เราไม่มีลูกบอลคริสตัล” เลฟฟิงเวลล์กล่าว “เราแค่วิ่งเร็ว เป็นผู้นำ และติดตามอย่างหนัก—และเขียนให้เร็วที่สุดเท่าที่เราจะทำได้”