Journey to Agile: Braze พลิกโฉมกระบวนการจัดการโครงการซอฟต์แวร์อย่างไร

การทำแผน

หลังจากการไตร่ตรอง เราตัดสินใจที่จะย้ายไปใช้วิธีการทดลองจริงสำหรับทีมวิศวกรรม—เราตัดสินใจว่าเราต้องการเป็น Agile มากขึ้น

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

คณะกรรมการ Agile นี้ในขณะที่เราขนานนามว่าเข้าหาสถานการณ์โดยคำนึงถึงหลักการสำคัญบางประการ:

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

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

ต่อไป เราต้องเผชิญกับการตัดสินใจหลักสองประการ: (1) เครื่องมือใดที่เราควรใช้เพื่อสนับสนุนกระบวนการใหม่ของเรา และ (2) วิธีที่เราควรเปิดตัวการเปลี่ยนแปลงในกระบวนการของเรา เราได้พูดคุย ประเมิน และสาธิตซอฟต์แวร์หลายชิ้น—และในที่สุด Jira ของ Atlassian ก็พิสูจน์แล้วว่าเป็นตัวเลือกที่เหมาะสมสำหรับเรา เป็นโซลูชันที่ได้รับการพิสูจน์แล้ว หลายคนในทีมของเรามีประสบการณ์ในการใช้งานแล้ว และทีมอื่นๆ ใน Braze ก็ใช้มันอยู่แล้ว ซึ่งเป็นการเปิดโอกาสในการทำงานร่วมกันข้ามทีมได้ดียิ่งขึ้น เพราะเราทุกคนทำงานภายในระบบเดียว

เมื่อต้องเลือกแผนการเปิดตัวสำหรับ Agile เรามีการตัดสินใจที่สำคัญบางประการที่ต้องทำ อันดับแรก เราจะฝึก/เปิดใช้งานทีมอย่างไร? เราสามารถจ้างโค้ช Agile ให้ผู้ที่มีประสบการณ์ในทีมทำงานฝึกอบรมคนอื่นๆ หรือหาที่ปรึกษาเพื่อช่วยเหลือ ประการที่สอง เราควรสร้างทีมในด้านวิศวกรรมที่มีประสบการณ์กับ Agile มาบ้างเพื่อรอการฝึกอบรมก่อนที่จะนำไปใช้หรือไม่

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

• เราไม่ต้องการให้แต่ละทีมเป็นเจ้าของวิธีที่เราทำ Agile และเรารู้สึกว่าการฝึกอบรมจะได้รับดีกว่าและคำแนะนำจะครอบคลุมมากขึ้นหากมาจากบุคคลที่สาม
• เราคิดว่าธุรกิจที่ปรึกษาจะมีเสถียรภาพและเชื่อถือได้มากกว่าโค้ช Agile แต่ละคน
• เราต้องการให้มีการฝึกอบรมขั้นพื้นฐานสำหรับทั้งองค์กรด้านวิศวกรรม และเริ่มต้นโดยไม่ต้องมีการสันนิษฐานใดๆ เกี่ยวกับความรู้ที่สมาชิกแต่ละคนในองค์กรมีเกี่ยวกับ Agile
• สุดท้ายเราต้องการให้โค้ชออกจากจุดหนึ่งเพื่อให้ชัดเจนว่าทุกคนในองค์กรของเรามีหน้าที่ดูแลกระบวนการต่อไป

การดำเนินการตามแผน

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

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

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

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

ผลลัพธ์

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

นอกจากนี้เรายังมีสถานที่ที่สอดคล้องกันมากขึ้นสำหรับสิ่งประดิษฐ์การออกแบบ เช่นเดียวกับความคาดหวังที่สอดคล้องกันมากขึ้นเกี่ยวกับสิ่งที่ "ทำ" จริงๆ สำหรับโครงการที่กำหนด การเห็นว่าทีมอื่นๆ กำลังทำงานอะไรอยู่นั้นกลายเป็นเรื่องง่าย และผู้คนจะเข้าใจวิธีทำงานร่วมกันได้ดียิ่งขึ้นกว่าเดิม

สิ่งที่ฉันสังเกตเห็นที่ส่วนท้ายของการเปลี่ยนแปลงนี้คือจำนวนคำขอดึงเปิดทั้งหมดในองค์กร ณ เวลาใดก็ตามลดลง แม้ในขณะที่เราทำมากขึ้นและเพิ่มขนาดทีมของเรา ด้วยการทำงานทีละน้อยและเน้นที่การตกแต่งสิ่งต่างๆ จำนวนรายการในเที่ยวบินจึงลดลงอย่างมาก

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

ซื้อกลับบ้าน

องค์ประกอบหลักสองประการของความพยายามของเราทำให้มั่นใจได้ถึงความสำเร็จ

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

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

มีอะไรอีกไหม

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