เรามีทีม SCRUM "ทั่วไป" และเรามุ่งมั่นที่จะทำงานเพื่อการวิ่งและยังคงมีงานในมือ เมื่อเร็ว ๆ นี้เราประสบปัญหาในการพยายามรวม / จัดการกับงานของนักพัฒนาที่ประสบผลสำเร็จมากเกินไปในการทำงานนอกกลุ่ม (เลือกที่จะทำงานนอกเวลาทำงานปกติ / การวิ่ง)

เพื่อยกตัวอย่างถ้าทีมงานใช้ 50 คะแนนในการทำงานสมมติว่าพวกเขาจะทำงานทั้งหมดให้เสร็จภายในกรอบ SCRUM ในตอนท้ายของการวิ่งและพวกเขาและ บริษัท มีความสุข หนึ่งในสมาชิกในทีมตัดสินใจที่จะทำงานด้วยตัวเองในรายการที่ค้างในเวลาว่างของตัวเอง พวกเขาไม่ได้ตรวจสอบในงานนี้ แต่แทนที่จะบันทึกไว้ (เราใช้ TFS และอยู่ในชั้นวาง)

วิธีจัดการกับสิ่งนี้? ปัญหาเล็กน้อย ..

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

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

วิธีบูรณาการงานที่ทำโดยสมาชิกที่ประสบความสำเร็จมากเกินไปใน SCRUM และกระบวนการที่คล่องตัวในการพัฒนาซอฟต์แวร์?

เอาล่ะดังนั้นใครบางคนกำลังเขียนโค้ดที่ยอดเยี่ยมที่ต้องทำอย่างกระตือรือร้น ด้วยการเน้นย้ำทั้งหมด:

ให้พวกเขา

มันก่อให้เกิดภาวะแทรกซ้อนในการต่อสู้ของคุณ มันมีความสำคัญในรูปแบบที่ยิ่งใหญ่ของสิ่งต่าง ๆ หรือไม่? หากเขาบรรลุสิ่งที่เขาควรจะทำให้เขาดำเนินการต่อและสร้างสิ่งที่ดีสำหรับคุณ

ฉันรู้จักโปรแกรมเมอร์ที่น่าทึ่งหลายคนที่ลาออกจาก บริษัท เพราะพวกเขาไม่ยอมให้โปรแกรมเมอร์นอกเหนือจากข้อ จำกัด ของระบบการประดิษฐ์เช่น Scrum (ฉันเองออกจากงานล่าสุดหลังจากได้รับการปฏิบัติเหมือนไม่มีอะไรมากไปกว่า QA) หากมีข้อร้องเรียนจากผู้พัฒนารายอื่นเกี่ยวกับอินพุต (ข้อร้องเรียนที่ถูกต้องสมบูรณ์แบบฉันอาจเพิ่ม) มันอาจเป็นการดีที่สุดที่จะแนะนำโปรแกรม "เวลา 20%" เพื่อให้เขา (และคนอื่น ๆ ) ทำสิ่งที่พวกเขาทำได้ดีที่สุด

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

มีสองสิ่งที่ฉันคิดว่าคุณควรพิจารณาที่นี่:

1. อย่าขัดขวางการไหลของความคิดสร้างสรรค์ของใครบางคน
   • หากนักพัฒนาซอฟต์แวร์ต้องการทำงานนอกเวลาทำงานให้ปล่อยพวกเขา
2. อย่าสร้างงานให้คนอื่น
   • หากนักพัฒนาซอฟต์แวร์ต้องการทำงานนอกเวลาทำงานแน่นอนว่านรกจะไม่สร้างงานให้ผู้อื่นมากขึ้น

ประเด็นที่ 2 น่าจะเป็นสิ่งที่ผู้พัฒนารายอื่นกังวล

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

ดังนั้นคุณจะทำอย่างไร

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

ท้ายที่สุดเขาเป็นส่วนหนึ่งของทีมดังนั้นทีมควรมีส่วนร่วมในการพัฒนารหัสทั้งหมด

อย่างไรก็ตามถ้างานของเขาฟังดูดีและสอดคล้องกับการออกแบบของทีมที่ตกลงกันไว้เขาจะสามารถใช้สิ่งที่เขาเขียนไปแล้ว (โบนัส!) ถ้าไม่มันจะบังคับให้เขาคิดเกี่ยวกับการออกแบบของเขาในครั้งต่อไปที่เขาตัดสินใจที่จะเริ่มต้น

วิธีนี้ไม่มีใครได้รับแจ้งNOและไม่มีใครสร้างงานพิเศษสำหรับพวกเขา

พาเขากลับเข้าทีม

คุณควรถามตัวเอง (หรือดีกว่าทีมรวมถึงผู้ที่เอาชนะได้มากเกินไป):

เหตุใดพฤติกรรมนี้จึงเป็นปัญหา

เนื่องจากคุณติดป้ายกำกับนักพัฒนาเป็นผู้มีผลมากฉันคิดว่างานของเขามีคุณภาพดีดังนั้นฉันจะสมมติว่านี่ไม่ใช่ปัญหา

แต่ดูเหมือนจะมีปัญหาอื่น ๆ :

• งานพิเศษไม่ผ่านการทดสอบอย่างเหมาะสม
• ไม่มีการบันทึกไว้
• ส่วนที่เหลือของทีมไม่ทราบ
• นักพัฒนาตัดสินใจเลือกสิ่งต่อไปที่จะใช้ไม่ใช่ PO
• นักพัฒนาไม่ได้รับคำติชมใด ๆ จากผู้มีส่วนได้ส่วนเสียที่หลากหลายเพื่อรวมไว้ในงานของเขา

ต่อไปทำไมฉันจะเป็น:

ทำไมนักพัฒนาถึงทำมัน?

• หากในตอนท้ายของการวิ่งไม่เหลืองานมากพอควรมีการตัดสินใจของทีม (รวมถึง PO) เกี่ยวกับสิ่งที่ต้องแก้ไขต่อไป ทำไมนักพัฒนาจึงหลีกเลี่ยงการตัดสินใจนี้

เมื่อคุณมีคำตอบสำหรับคำถามเหล่านี้คุณสามารถเริ่มตอบคำถามของคุณเอง:

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

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

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

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

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

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

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

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

เราเผชิญกับสิ่งเดียวกันเช่นกันโดยทั่วไปเราทำอะไรประมาณ 20 คะแนน แต่ในสัปดาห์ที่แล้วหรือแม้กระทั่งช่วงกลางของการวิ่งเราหมดภาระการเขียนโปรแกรมอย่างไรก็ตามเนื่องจากการทดสอบและกระบวนการที่เหลือเราไม่เสี่ยงที่จะเลือก PBI อีก โปรแกรมเมอร์ทำคือการมองเข้าไปใน Backlog และเริ่มพัฒนา PBIs ในอนาคต (เงียบ ๆ ) และแจ้งให้ทีมที่เหลือในการวางแผนว่า PBI พร้อมสำหรับการตรวจสอบและทดสอบโค้ด! เหมือนที่คุณพูด

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

เพียงแค่เราเริ่มพยากรณ์ PBIs มากกว่ามุ่งมั่น การคาดการณ์โดยทั่วไปหมายถึงเราเลือก 25 คะแนนที่การวางแผนและเริ่มการวิ่งและเมื่อโปรแกรมเมอร์ได้รับอิสระที่การวิ่งเนื่องจากไม่มีการเข้ารหัสอีกต่อไปดังนั้นเขา / เธอจึงเลือก PBI หนึ่งในอนาคตและวางไว้ใน Sprint ปัจจุบันและเริ่มทำงาน ในนั้นถ้า PBI สามารถผ่านกระบวนการทั้งหมด (การทดสอบการรวมและอื่น ๆ ) ภายในการวิ่งเดียวกันมันเป็นคะแนนโบนัสสำหรับทีมถ้าไม่ใช่เราจะไม่ล้มเหลวในการวิ่งเพราะ PBI นั้นและเพียงแค่ดำเนินการงานที่เหลืออยู่ ( ทดสอบหรือ meging หรืออื่น ๆ ) ไปยังการวิ่งครั้งต่อไปและเล่นโป๊กเกอร์อีกครั้งสำหรับงานที่เหลืออยู่ ดังนั้นจึงสามารถทำได้ในการวิ่งที่แตกต่างกันสองกรณีในกรณีที่เลวร้ายยิ่ง ฉันรู้ว่ามันอาจฟังดูเหมือน Scrumbut แต่จริงๆแล้วมันปรับปรุงวิธีการทำงานของเรา ฉันสามารถสรุปผลประโยชน์ได้ดังนี้:

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

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

บางคำตอบอื่น ๆ ได้ชี้ให้เห็นว่านักพัฒนา "overachieving" คือ "คนโกง" หรือ "ละเมิดหลักการของการต่อสู้" สิ่งนี้ไม่ถูกต้องและผู้พัฒนานี้ควรได้รับการสนับสนุน (แม้ว่าคุณไม่ควรขอให้คนอื่นทำงานพิเศษใด ๆ ในช่วงต่อเวลาพิเศษนี้ แต่คุณสามารถให้คำแนะนำและช่วยส่งเสริมแนวคิด)

ไม่มีอะไรใน Scrum ที่จะกำหนดวิธีการทำงานของผู้คนและสิ่งพิเศษที่เขาทำจะถูกรวมเข้ากับความเร็วของทีม

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

น่าสนใจที่คุณอธิบายนักพัฒนาว่า "overachieving" ฉันคิดว่านี่หมายความว่าเขากำลังเพิ่มคุณค่ามากกว่าสมาชิกในทีมคนอื่น ๆ

ความยากลำบากในการทำงานพิเศษที่สร้างขึ้นบ่งบอกว่ามีบางสิ่งที่ไม่เหมาะสม (หรืออาจผิดปกติ) ในทีมของคุณ

หากเป็นกรณีนี้คุณควรถามตัวเองว่าทำไมเขาถึงประสบความสำเร็จมากกว่านี้ด้วยความพยายามพิเศษเล็กน้อย?

เป็นไปได้หรือไม่ที่คุณจะทำให้คนอื่น ๆ ในทีมประสบความสำเร็จมากขึ้น?

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

ให้พวกเขาเป็นครูด้วย

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

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

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

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

นอกจากนี้คุณยังสามารถหางาน 'ด้าน' สำหรับนักพัฒนาที่ดีที่สุดเมื่อพวกเขาไม่ได้ทำงานเช่นการปรับปรุงชุดเครื่องมือที่ทุกคนใช้งานเรียกใช้กลุ่มอภิปรายชมรมหนังสือทางเทคนิคหรือมีส่วนร่วมในโครงการองค์กรอื่น ๆ

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

คำถามที่แท้จริงคือคุณต้องการให้ dev นี้ทำสิ่งที่เขาทำหรือไม่ ฉันคิดว่าหลายแง่มุมมีบทบาทสำคัญในการตอบคำถามนั้น:

1. โปรแกรมเมอร์ทำงานดีหรือไม่
2. ทุกคนโอเคกับเขาที่ทำงานด้วยตัวเอง (ไม่ว่าจะดีหรือไม่ดี) เขาหลบกระบวนการออกแบบหลังจากทั้งหมด!
3. มีการจ่ายชั่วโมงพิเศษหรือไม่

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

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

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

ทีม (ไม่ใช่ PO หรือ ScrumMaster) จำเป็นต้องจัดการกับโปรแกรมเมอร์โกง