ใหญ่เกินกว่าจะปรับขนาดได้ – คู่มือขนาดทีม 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 ในทุกระดับ