#priwreadbooks Agile Coaching — Chapter 7 — Planning Ahead (สรุป)

Photo by airfocus on Unsplash

Previous chapter:

• Chapter 1 — Starting the Journey
• Chapter 2 — Working with People
• Chapter 3 — Leading Change
• Chapter 4 — Building an Agile Team
• Chapter 5 — Daily Standup
• Chapter 6 — Understanding What to Build

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

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

การวางแผนก็เหมือนการทำผัดผัก

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

ความลับของสูตรนี้อยู่ที่การเตรียมตัว

เดินทางผ่านขั้นตอนพื้นฐานต่อไปนี้เพื่อสร้างแผน

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

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

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

ในระหว่างการประชุม เมื่อการสนทนาในทีมเลื่อนลอย คุณสามารถปรับโฟกัสใหม่ได้โดยเตือนทีมเกี่ยวกับวาระการประชุม

ทำความเข้าใจเกี่ยวกับลำดับความสำคัญ

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

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

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

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

ช่วงเวลาการประมาณการ

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

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

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

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

หากการประชุมใช้ระยะเวลายาวนานเกินไป ให้ลองนำนาฬิกาจับเวลาในครัวมา ใครก็ตามในที่ประชุมสามารถใช้กรอบเวลา (timebox) สนทนาต่อไปได้อีกสิบนาที สิ่งนี้ถือเป็นสัญญาณในการยุติการสนทนาและดำเนินการเรื่องอื่นต่อ

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

ตรวจสอบและยอมรับความสามารถของทีม

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

หากทีมเพิ่งเริ่มต้นและยังไม่มีข้อมูลความเร็ว ให้ลองใช้วิธีนี้

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

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

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

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

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

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

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

มันไม่สมเหตุสมผลเลยที่จะวางแผนรอบการทำงานที่ใช้เวลานานกว่าสามเดือน ให้ใช้การวาง Roadmap แทน

หากทีมทำการเปลี่ยนแปลงเพียงเล็กน้อยเพื่อรองรับแอปพลิเคชันที่ใช้งานจริง แทนที่จะพัฒนาผลิตภัณฑ์อย่างจริงจัง อาจไม่มีประโยชน์ในการรวมทีมเข้าด้วยกันเพื่อสร้างแผนระยะยาว คุณควรจะใช้คัมบัง (Kanban) โดย Karl Scotland, EMC Consulting ซึ่งเน้นให้ทีมปรับปรุงขั้นตอนการทำงานแทน

Kanban

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

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

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

การติดตาม

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

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

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

อุปสรรคที่อาจเจอ

ลูกค้าไม่รู้ว่าต้องการอะไร

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

ทีมอาจถูกขอให้ทุ่มเททำงานมากกว่าที่จะสามารถส่งมอบได้จริง

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

Yesterday’s Weather by Lasse Koskela, Reaktor Innovations ประสิทธิภาพการทำงานของทีมจะไม่ดีขึ้นจากการคิดเพ้อฝันและการ “พยายามให้หนักขึ้น”

แย่ที่สุดคือ มันจะแย่ลงภายใต้แรงกดดันที่มากเกินไป

แผนการเปลี่ยนแปลงระหว่างการทำซ้ำ

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

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

การประชุมมีความขัดแย้งหรือตึงเครียดมาก

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

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

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

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

ทีมมีความเร็วลดลง

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

การวางแผนไม่เข้าท่า

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

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