SAFe เป็นสิ่งที่ตรงกันข้ามกับสิ่งที่บริษัทผลิตภัณฑ์ที่แข็งแกร่งจะใช้ มันถูกเรียกว่า 'เปรียวในขนาด' มันไม่คล่องตัว มันเป็นเพียงการตลาด
“บริษัทขนาดใหญ่จำนวนมากติดกระบวนการนี้ และพวกเขาคิดว่าคำตอบคือกระบวนการ… แม้ว่าพวกเขาอาจใช้คำว่า agile แต่พวกเขาก็มักจะใช้กระบวนการไร้สาระเหล่านี้ เช่น SAFe หรือ LeSS สิ่งเหล่านี้เป็นสิ่งที่ตรงกันข้ามกับสิ่งที่บริษัทผลิตภัณฑ์ที่ดีจะใช้ อันที่จริง ฉันไม่สามารถชี้ไปที่บริษัทผลิตภัณฑ์ที่แข็งแกร่งแห่งเดียวที่ใช้สิ่งเหล่านี้ได้ พวกมันถูกเรียกว่า Agile at Scale พวกเขาไม่คล่องตัวเลย มันเป็นเพียงการตลาด และคนเหล่านี้ก็ตกหลุมรักช่องทางการตลาด
— มาร์ตี้ คาแกน, 2022
Marty Cagan เป็นผู้ก่อตั้งและหุ้นส่วนของ Silicon Valley product Group (SPVG) และเป็นผู้เขียนหนังสือขายดี INSPIRED และ EMPOWERED Marty ผู้มีประสบการณ์ในอุตสาหกรรมเป็นเวลา 20 ปีในฐานะผู้นำผลิตภัณฑ์ ปัจจุบันทำงานร่วมกับบริษัทเทคโนโลยีจากทั่วโลกเพื่อช่วยขับเคลื่อนการเปลี่ยนแปลงผลิตภัณฑ์ด้วยนวัตกรรม ความเร็ว และความคล่องตัว เขามักถูกเรียกว่า "บุคคลที่มีอิทธิพลมากที่สุดในพื้นที่ผลิตภัณฑ์"
ทีแอลดีอาร์;
วิธีการที่คล่องตัวสมัยใหม่นำระบบที่ซับซ้อนมาใช้เพื่อติดตามว่าทีมทำงานที่พวกเขามุ่งมั่นในระดับ PI สำเร็จหรือไม่ หากไม่มีกลยุทธ์การจัดการผลิตภัณฑ์ที่เหมาะสม (เนื่องจากสิ่งนี้ไม่สามารถเกิดขึ้นได้สองสามวันต่อไตรมาส) วิศวกรจะใช้เวลาจำนวนมากในการโกหกเกี่ยวกับการประมาณค่าของตน คาดไม่ถึง และพยายามสร้างเกมให้กับหน่วยวัดทั่วไป สิ่งนี้ทำให้เกิดปัญหาด้านแรงจูงใจอย่างมากกับวิศวกร การรับรู้ความสามารถของตนเองซึ่งเป็นส่วนหนึ่งของแบบจำลองความเป็นอยู่ที่ดีทางจิตใจ ("แบบจำลองของซิมเมอร์แมนที่อธิบาย "การควบคุมตนเอง") คือความเชื่อที่ว่าคุณสามารถทำอะไรบางอย่างได้และเป็นแรงจูงใจที่อยู่รอบตัวสิ่งนั้น หากลำดับเวลาและการประมาณการของคุณไม่สมเหตุสมผลและคุณใช้เวลาโกหกเกี่ยวกับเรื่องนี้นานเกินไป คุณจะไม่สามารถสร้างโครงสร้างความเชื่อหรือแรงจูงใจในการทำสิ่งนั้นได้ ซึ่งจะส่งผลต่อความสนใจของคุณที่จะพยายามทำมัน
SAFe คืออะไร?
Scaled Agile Framework® (SAFe®) คือชุดของรูปแบบองค์กรและเวิร์กโฟลว์สำหรับการนำแนวทางปฏิบัติแบบ Agile ไปใช้ในระดับองค์กร กรอบการทำงานนี้เป็นองค์ความรู้ที่ประกอบด้วยคำแนะนำที่มีโครงสร้างเกี่ยวกับบทบาทและความรับผิดชอบ วิธีการวางแผนและจัดการงาน และค่านิยมที่จะยึดถือ
SAFe การกล่าวอ้าง มีผู้เชี่ยวชาญมากกว่า 1,000,000 คนที่ได้รับการฝึกอบรมใน SAFe ในกว่า 110 ประเทศ แล้วมันต้องมีอะไรสักอย่างใช่ไหม?
การใช้งาน SAFe
ขั้นตอนแรก ตามที่กรอบ SAFe เสนอมา คือการเลือกกลุ่มพนักงานเพื่อเป็นที่ปรึกษาโครงการที่ปลอดภัย
“ฝึกอบรมตัวแทนการเปลี่ยนแปลงแบบ Lean-Agile ในฐานะที่ปรึกษาโปรแกรม SAFe® (SPC) ที่ได้รับการรับรอง”
การรับรองจะอยู่ที่ประมาณ 3,000 ดอลลาร์สหรัฐฯ ต่อ SPC และไม่รวมค่าใช้จ่ายในการส่งผู้นำและพนักงานทั่วไปของคุณไปรับการรับรองอื่นๆ ที่ SAFe แนะนำให้องค์กรของคุณดำเนินการต่อไป
ผลลัพธ์ที่ตั้งใจไว้? ตอนนี้คุณมีพนักงานที่ทุ่มเทให้กับการใช้ชีวิตและหายใจด้วย SAFe และผลักดันวาระ SAFe ทั่วทั้งองค์กรของคุณ นี่เป็นโครงการปิรามิดในการดำเนินการอย่างแท้จริง
แบรนด์เปรียว
สารสกัดต่อไปนี้เกี่ยวกับ “branded agile” นำมาจาก “การทำความเข้าใจ Fake Agile” โดย Steve Denning, 2019
รูปแบบที่โชคร้ายอย่างยิ่งของ “ความคล่องตัวของแบรนด์” เกี่ยวข้องกับการปรับขนาดเฟรมเวิร์ก แผนการเหล่านี้มีจุดมุ่งหมายในการช่วยเหลือบริษัทที่มีบางทีมนำแนวปฏิบัติแบบ Agile ไปใช้ และต้องการแก้ไขความตึงเครียดระหว่างทีม Agile และระบบ back-office ขององค์กร (เช่น กลยุทธ์ การวางแผน งบประมาณ ทรัพยากรบุคคล การเงิน) ซึ่งโดยทั่วไปแล้วจะมีขนาดใหญ่ใหญ่โต และระบบราชการ
ความท้าทายมักถูกนำเสนอว่าเป็น "การขยายขนาดความคล่องตัว" ปัญหาก็คือ หากบริษัทกำลังคิดที่จะ "ขยายขนาดความคล่องตัว" แสดงว่ามันมาผิดทางแล้ว ความท้าทายของความคล่องตัวอย่างแท้จริงคือวิธีลดขนาดระบบที่มุ่งเน้นภายในและเสาหินขนาดใหญ่ให้เป็นงานที่สามารถดำเนินการโดยทีมเล็กๆ ที่มุ่งเน้นลูกค้าซึ่งจัดการตนเองได้
รูปแบบที่น่ากังวลเป็นพิเศษคือ Scaled Agile Framework หรือ SAFe โดยพื้นฐานแล้ว นี่คือระบบราชการที่เข้ารหัส ซึ่งลูกค้าแทบไม่ได้อยู่เลย ปัจจุบันแพร่หลายในบริษัทขนาดใหญ่ เพราะมันทำให้ฝ่ายบริหารมีอำนาจที่จะเรียกตัวเองว่ามีความคล่องตัวและทำสิ่งที่พวกเขาทำมาตลอด โดยพื้นฐานแล้ว จะเป็นผู้ใต้บังคับบัญชาทีมที่คล่องตัวไปสู่ระบบราชการ แทนที่จะทำสิ่งที่จำเป็นเพื่อให้บรรลุความคล่องตัวทางธุรกิจ กล่าวคือ เปลี่ยนระบบที่มุ่งเน้นภายในแบบเสาหินขนาดใหญ่ให้เป็นการเตรียมการที่งบประมาณ ทรัพยากรบุคคล การเงิน และอื่นๆ มีความยืดหยุ่นและมุ่งเน้นจากภายนอกในการสนับสนุน ทีมงาน Agile ในการดำเนินงาน บทบาทที่ไม่มีนัยสำคัญของลูกค้าในแผนภูมิด้านบนเป็นการบ่งบอกถึงปัญหา
มีความเสี่ยงที่ SAFe จะทำให้ Agile ของแท้เสื่อมเสีย มันเป็นภาพประกอบของกฎของ Gresham: เงินที่ไม่ดีจะขับไล่สิ่งที่ดีออกไป เมื่อสิ่งนี้เกิดขึ้น SAFe คือตัวอย่างของ "Agile จอมปลอม" เป็นไปได้ว่าเมื่อ SAFe ถูกนำไปใช้โดยผู้จัดการที่มีกรอบความคิดแบบ Agile อย่างแท้จริง ผลกระทบด้านลบของ SAFe ก็สามารถบรรเทาลงได้ คำถามของฉันคือ: ทำไมทุกคนที่มีแนวคิดแบบ Agile อย่างแท้จริงถึงใช้ SAFe ตั้งแต่แรก?
การวิพากษ์วิจารณ์ SAFe ทั่วไป
ด้านล่างนี้คือการรวบรวมประเด็นเล็กๆ น้อยๆ ที่ไม่สมควรได้รับส่วนของตนเองในบทความนี้:
- SAFe อธิบายว่าทีมพัฒนาประกอบด้วย “ผู้พัฒนาและผู้ทดสอบ” แทนที่จะเป็นการทำงานแบบข้ามสายงานโดยสมบูรณ์
- SAFe พยายามบังคับใช้หลักปฏิบัติด้านคุณภาพโค้ดที่ดัดแปลงมาจาก XP
- SAFe บอกว่า "พัฒนาตามจังหวะ ส่งมอบตามต้องการ" แต่ยังใช้ "Release Trains" อีกด้วย รถไฟปล่อยสินค้าเป็นการเพิ่มขั้นที่สามารถจัดส่งได้มาก สิ่งนี้ไม่ได้ให้บริการตามความต้องการ โดยจะจัดส่งตามกำหนดการทุกๆ 10 สัปดาห์
- SAFe แนะนำว่า Sprint ครั้งที่ 6 ควรมีไว้สำหรับ "การแข็งตัว นวัตกรรม และการวางแผน" นี่คือรูปแบบการเริ่มต้นและหยุด เมื่อใดก็ตามที่มีการหยุดก็จะมีของเสียที่ไม่จำเป็นเกิดขึ้น ธุรกิจและลูกค้าไม่ได้เข้านอนเป็นเวลา 2 สัปดาห์ทุกๆ 3 เดือน และนี่ไม่เหมาะกับโมเดล DevOps ที่แท้จริง
- SAFe บอกว่าคุณต้องการคนอย่างน้อย 50 คนเพื่อทำ SAFe
- SAFe ถือว่าทุกโครงการที่คุณทำอยู่มีขนาดใหญ่ และต้องใช้หลายทีมจึงจะเสร็จสมบูรณ์ นี่ไม่ใช่กรณีในความเป็นจริง ทีมงานที่มุ่งเน้นผลิตภัณฑ์/สอดคล้องกันสามารถส่งมอบแบบ end-to-end ได้ด้วยตนเองและตามความต้องการ
- SAFe อ้างว่ามีความคล่องตัวและคล่องตัว แต่ขัดแย้งกับหลักการแบบลีนหลายประการ และคำแถลงการณ์ที่คล่องตัวเกือบทั้งหมด
- SAFe มีความซับซ้อนมากเกินไปตามวัตถุประสงค์และอัปเดตข้อกำหนดทุกปีเพื่อทำการตลาดและจำหน่ายใบรับรอง
- SAFe ได้รับการบรรจุและออกแบบอย่างตั้งใจเพื่อดึงดูดผู้จัดการและผู้บริหารที่ไม่เข้าใจความคล่องตัวและไม่ต้องการมุ่งมั่นที่จะเปลี่ยนแปลงผลิตภัณฑ์อย่างแท้จริง
การวิพากษ์วิจารณ์การวางแผน PI
การเพิ่มโปรแกรม (PI) คือกล่องเวลาที่ Agile Release Train (ART) ส่งมอบมูลค่าที่เพิ่มขึ้นในรูปแบบของการทำงาน ซอฟต์แวร์และระบบที่ผ่านการทดสอบแล้ว โดยทั่วไป PI จะมีความยาว 8–12 สัปดาห์ รูปแบบที่พบบ่อยที่สุดสำหรับ PI คือการทำซ้ำการพัฒนาสี่ครั้ง ตามมาด้วยการทำซ้ำด้านนวัตกรรมและการวางแผน (IP) หนึ่งครั้ง — การเพิ่ม PI, ปลอดภัย, 2021
การสร้างแผนภูมิแกนต์และใช้คำว่า 'Sprint' ตรงกลาง 10 ครั้งไม่ใช่ Agile มันคือน้ำตก
ที่ปรึกษาโปรแกรม SAFe:
“มันไม่ใช่แผนภูมิแกนต์ มันเป็นแผนภูมิ PERT”
SAfe ดูเหมือนจะท้าทายสิ่งนี้ด้วยการประกาศรูปแบบต่างๆ ของ PLAN, DO, ACT แต่โดยหลักการแล้ว คุณกำลังเตรียมงาน 12 สัปดาห์ซึ่งครั้งหนึ่งเคยนำเสนอต่อผู้บริหารระดับสูงถึงความเป็นจริงที่พวกเขากำลังติดตามสิ่งที่พวกเขาคิดว่าเป็นความมุ่งมั่นที่จะทำงานนั้นให้สำเร็จ คุณสามารถโต้แย้งได้มากเท่าที่คุณต้องการว่านี่ไม่ใช่จุดประสงค์ของ PI แต่ในโลกแห่งความเป็นจริง นี่คือวิธีที่ฝ่ายบริหารมักจะตีความ และ SAFe จะสนับสนุนเฉพาะพฤติกรรมที่ไม่ดีนี้เท่านั้น
แผนภูมิ PERT ของคุณ - หรือบอร์ด SAFe PI ซึ่งเป็นหนึ่งในองค์ประกอบสำคัญที่ออกมาจาก PI - อาจดูเหมือนมีคุณค่าโดยการกำหนดและจัดการการพึ่งพาระหว่างทีม แต่นี่เป็นการแบ่งแยกความคล่องตัวที่ผิดพลาด บริษัทที่เน้นผลิตภัณฑ์อย่างแท้จริงจะสร้าง "สถาปัตยกรรมที่เชื่อมโยงกันอย่างหลวมๆ" ซึ่งช่วยให้ทีมทดสอบและปรับใช้การเปลี่ยนแปลงใดๆ ได้อย่างอิสระโดยแยกจากกัน โดยไม่ต้องพึ่งพาการสนับสนุนและบริการจากบุคคลอื่น
รูปแบบการต่อต้านอื่นๆ ที่ SAFe สนับสนุน (แม้ว่าอาจถูกโต้แย้งอีกครั้งผ่านการใช้งานที่ไม่ดี) ก็คือคุณตอบสนอง/ปรับตัวให้เข้ากับความต้องการของลูกค้าที่เปลี่ยนแปลงเพียง 4 ครั้งต่อปี
PI ขึ้นอยู่กับการประมาณค่าสัมพัทธ์ ดูบทความของฉันเกี่ยวกับสาเหตุที่ 'การประมาณสัมพัทธ์เป็นการเสียเวลา'
ช่วงเวลาการวางแผนคงที่ไม่ตรงกับความเป็นจริง ในระบบลีน การวางแผนควรเกิดขึ้นตามความต้องการ ไม่ใช่ตามระยะเวลาที่กำหนด
ในความเป็นจริง เมื่อดำเนินการวางแผนคงที่ ผลลัพธ์จะมี 2 ประการเสมอ:
- ทีมวิศวกรทำงานให้เสร็จก่อน PI ถัดไป พวกเขาจึงทำงานน้อยลงในช่วงเวลาที่เหลือโดยไม่มีทิศทางที่ชัดเจนหรือเริ่มวางแผนใหม่นอก PI
- ทีมวิศวกรทำงานให้เสร็จหลังจาก PI ถัดไป ในระหว่าง PI พวกเขาวางแผนงานใหม่ก่อนที่งานเดิมจะเสร็จสิ้น เมื่อ PI สิ้นสุดลง พวกเขาอาจกลับไปทำสิ่งที่พวกเขาทำอยู่ก่อนหน้านี้หรือตัดบางส่วนออกไปเพื่อทำงานชิ้นใหม่ ซึ่งทำให้เกิดปัญหาการสลับบริบทเพิ่มเติม
วิศวกรจะไม่มีส่วนร่วมระหว่างเซสชันการวางแผน PI 4 วัน ทีมปฏิบัติการ, SRE หรือ DevOps บ่นว่าพวกเขาไม่สามารถหยุดเวลาได้และต้องทำงานนานขึ้น วิศวกรจากสถานที่และโซนเวลาที่แตกต่างกันจะถูกบังคับให้เข้าร่วมการโทรตั้งแต่เช้าตรู่หรือสายในตอนเย็น
หากคุณปรับใช้ตามความต้องการ เติมและอัปเดต Backlog ของคุณโดยอัตโนมัติตามสัญญาณเริ่มต้นและหยุด ฝึกฝนการรวบรวมความต้องการอย่างต่อเนื่อง ติดตามงานตั้งแต่ต้นน้ำไปจนถึงการพัฒนาวิศวกร (ดังนั้นการจัดการผลิตภัณฑ์จริง) อบในวงจรป้อนกลับโดยเร็วที่สุด และ ทำงานในรูปแบบการจัดส่งอย่างต่อเนื่อง จึงไม่จำเป็นต้องวางแผนขนาดใหญ่เพื่อขยายออกไป จึงเป็นการเสียเวลา
แนวทางปฏิบัติที่ดีที่สุดที่ท้าทาย
สุดท้ายจากบล็อกโพสต์โดย Dan North...
องค์กรต่างๆ มักจะแนะนำ Best Practices เป็นส่วนหนึ่งของโครงการเปลี่ยนแปลงหรือโครงการริเริ่มด้านคุณภาพ สิ่งเหล่านี้อาจมีหลายรูปแบบ ตั้งแต่ "หนังสือทำอาหาร" และเอกสารสรุปไปจนถึงวิธีการที่นำโดยที่ปรึกษาเต็มรูปแบบ พร้อมด้วยการตรวจสอบและรับรองที่จำเป็น
บทความนี้จะแนะนำโมเดลการเรียนรู้ของ Dreyfus เพื่อท้าทายกลยุทธ์ในการใช้ Best Practices อย่างไร้เดียงสา และแสดงให้เห็นว่าสิ่งเหล่านี้ไม่เพียงแต่ล้มเหลวในการช่วยเหลือ แต่ยังส่งผลกระทบเชิงลบอย่างรุนแรงต่อผู้ปฏิบัติงานชั้นนำของคุณอีกด้วย
— แดน นอร์ธ, 2008
แล้วทำไมใครก็ตามที่มีแนวคิด Agile อย่างแท้จริงถึงใช้ SAFe ตั้งแต่แรก?
