ใหญ่เกินกว่าจะปรับขนาดได้ – คู่มือขนาดทีม Scrum ที่เหมาะสมที่สุด

เผยแพร่แล้ว: 2022-03-11

ฟังเวอร์ชั่นเสียงของบทความนี้

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

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

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

คุณควรเริ่มสร้างทีมที่สองเมื่อใด

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

ผู้เชี่ยวชาญพูดอะไร?

Jeff Bezos ผู้ก่อตั้ง Amazon ใช้กฎสองพิซซ่าสำหรับทั้งการประชุมและทีม นั่นหมายความว่าแต่ละคนควรมีคนมากเท่าที่พิซซ่าสองตัวสามารถกินได้ในช่วงกลางวัน

กฎสองพิซซ่าสำหรับทีมต่อสู้

Scrum Guide แนะนำให้มีสมาชิกในทีมระหว่างสามถึงเก้าคนที่กำลังดำเนินการงานในมือของ Sprint นั่นหมายความว่าคุณจะไม่รวมเจ้าของผลิตภัณฑ์หรือ scrum master ไว้ในยอดรวม เว้นแต่ว่าคนใดคนหนึ่งกำลังใช้งานรายการงานค้างของ sprint

ตัวเลขเหล่านี้ดูเหมือนจะสมเหตุสมผล แต่ก็ยังมีคณิตศาสตร์อยู่เบื้องหลัง ถ้าคุณนึกถึงทีม ทุกคนก็เหมือนโหนดและเชื่อมโยงกับโหนดอื่นๆ นี่คือความสัมพันธ์ระหว่างบุคคลระหว่างเพื่อนร่วมทีม พวกเขาสามารถเป็นมิตร แข่งขันกัน อาฆาตแค้น หรือเอาใจใส่ ไม่ว่าความสัมพันธ์ระหว่างคนสองคนจะเป็นเช่นไร แต่ก็ยังเป็นความเชื่อมโยงที่ต้องใช้ความสามารถทางจิตจากแต่ละคน เมื่อทีมเติบโตขึ้น จำนวนลิงก์เหล่านี้จะไม่เติบโตเป็นเส้นตรง สูตรสำหรับการเชื่อมโยงระหว่างโหนดคือ \(n(n-1)/2\) นี่คือแผนภูมิการเติบโตของลิงก์:

จำนวนลิงค์ระหว่างสมาชิกในทีม

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

สัญญาณว่าทีมกำลังโตเกินไป

การต่อสู้รายวัน

บางครั้งเรียกว่า standup รายวัน scrum รายวันเป็นการรวมตัวกันของทั้งทีมเพื่อหารือเกี่ยวกับความคืบหน้าและอุปสรรคของการวิ่ง Scrum Guide แนะนำให้จับเวลาเป็นเวลา 15 นาที และนั่นเป็นการทดสอบสารสีน้ำเงินที่ดีสำหรับขนาดทีม หากคุณเริ่มสังเกตเห็นว่าทีมของคุณกำลังข้ามขีดจำกัด 15 นาที นั่นอาจบ่งบอกถึงหนึ่งในสองสิ่งต่อไปนี้:

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

กรูมมิ่งและการวางแผนการวิ่ง

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

เช่นเดียวกับการต่อสู้รายวัน อย่าสับสนระหว่างการวางแผนที่ไม่มีประสิทธิภาพกับทีมที่ใหญ่เกินไป ท้ายที่สุด หน้าที่ของ scrum master ก็คือการทำให้พิธีการ scrum นั้นมีประสิทธิภาพและประสิทธิผล

ย้อนหลัง

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

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

วิธีแยกทีม

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

ข้อควรพิจารณาในการแยกทีม

ขวัญกำลังใจของทีม

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

ทีมข้ามสายงาน

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

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

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

ทีมงานควรมี Backlogs แยกกันหรือไม่?

หากทีมแตกแยก คำถามทั่วไปก็คือพวกเขาควรจะทำงานที่ค้างอยู่หรือแยกกัน เราสามารถดูที่ Scaled Agile Framework เพื่อเป็นแนวทางได้

Scrum@Scale

Scrum@Scale เป็นวิธีการที่พัฒนาโดยผู้สร้าง Scrum Guide Scrum@Scale ไม่ได้กำหนดไว้ล่วงหน้าและไม่ได้ระบุวิธีจัดการกับงานค้างของผลิตภัณฑ์โดยเฉพาะ อย่างไรก็ตาม มีข้อสังเกตสองประการ:

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

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

Scrum ขนาดใหญ่ (LeSS)

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

วิธีติดตามข่าวสารล่าสุด

สำหรับผู้จัดการผลิตภัณฑ์ หลายทีมหมายถึงงานที่ติดตามความคืบหน้าและตอบคำถามมากขึ้น

ติดตามข่าวสารหลังแยกทีม

จัดลำดับความสำคัญของการประชุม

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

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

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

มีส่วนร่วมมากขึ้นด้วย Scrum Masters

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

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

แนะนำ Scrum of Scrums

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

พิจารณาขยายทีมผลิตภัณฑ์

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

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

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

บทสรุป

เมื่อทีมของคุณเติบโตขึ้น คุณมักจะเริ่มสังเกตเห็นสัญญาณบางอย่างที่บ่งบอกว่าทีมของคุณมีขนาดใหญ่เกินไป โดยเฉพาะอย่างยิ่งใน:

  • การต่อสู้รายวัน หากคุณใช้กรอบเวลา 15 นาทีในการแย่งชิงรายวันและเห็นว่าผู้คนเริ่มหมดความสนใจ
  • การวางแผนการวิ่ง หากคุณตกอยู่ในภาวะชะงักงันระหว่างการวางแผนการวิ่งบ่อยขึ้นเรื่อยๆ
  • ย้อนหลัง. หากคุณเริ่มสังเกตเห็นว่าการประนีประนอมในช่วงหวนกลับกลายเป็นเรื่องยากขึ้น

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

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

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

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

ด้วยการใช้คำแนะนำเหล่านี้ คุณควรจะสามารถแบ่งทีมได้อย่างชัดเจน หากทีมของคุณเติบโตขึ้นเรื่อยๆ และคุณจะเพิ่มทีมมากขึ้นอีกในอนาคต คุณควรอ่านเกี่ยวกับ Scaled Agile Framework ซึ่งให้คำแนะนำเกี่ยวกับโครงสร้างและกระบวนการสำหรับ Agile ในทุกระดับ