#How to stop the vicious cycles of sprints
ในโลกทุกวันนี้ เราสามารถทำงานจากที่ไหนก็ได้ เวลาทำงานเริ่มเบลอ และ office hour เริ่มไม่มีความหมาย แม้แต่เวลาเริ่มของ sprint ใหม่ ก็ไม่มีเส้นแบ่งที่ชัดเจน เหมือนทำไปอย่างต่อเนื่อง เพราะกระบวนการพัฒนาซอฟต์แวร์มักจะเป็นแบบวนไปเรื่อยๆเพื่อให้เกิด incrementals เป็นหัวใจหลักของการทำ agile development แต่บางครั้งเคยลองนึกหรือไม่ว่า มันควรจะเป็นแบบนั้นซ้ำๆไปเรื่อยๆ หรือเปล่า หรือมันควรจะมีเวลาที่เราต้องทำอะไรช้าลงหรือหยุดพัก…ซักนิดนึง
ในการมอง agile development เรามักจะเปรียบเทียบกับรถยนต์อยู่บ่อยครั้ง ถ้าอยากสร้างรถยนต์ซักคัน เราจะเริ่มจากการสร้างสเก็ตบอร์ดขายก่อน เมื่อขายสเก็ตบอร์ดให้ลูกค้าได้แล้ว ก็เริ่มสร้างจักรยาน มอเตอร์ไซค์ แล้วค่อยสร้างรถยนต์
Approach แบบนี้ใช้จุดเด่นของการเพิ่ม feature เข้าไปเรื่อยๆ ในขณะเดียวกันก็มอบ value ให้กับ user อย่างสม่ำเสมอ ทีมงานค่อยๆสร้างแรงเหวี่ยง ในทุกๆ 2-3 สัปดาห์ จนเราได้ product ที่ใช่ แต่ทุกๆช่วงเวลา เราก็ได้เพิ่ม complexity เข้าไปด้วยตามขนาดและ scope ที่เพิ่มขึ้น
ถึงแม้ Agile ให้ความสำคัญกับ incremental ที่เพิ่มเข้ามา และให้เวลากับการจัดการสิ่งที่เป็น unknowns ได้เป็นอย่างดี แต่ Agile ที่แปลว่าคล่องแคล่วว่องไว ก็ต้องการ speed ด้วยเช่นกัน แต่ละ sprint ทีมงานจะต้องแก้ไข feedback ที่ได้จาก user อย่างรวดเร็วแล้วปรับ product ให้สอดคล้องกับความต้องการที่เปลี่ยนไป ซึ่งกระบวนการนี้อยู่บนพื้นฐานที่ว่า โดยธรรมชาติของซอฟต์แวร์มีการเปลี่ยนแปลงได้ตลอดเวลา ซึ่ง Agile มีกิจกรรมและ meeting ที่ช่วยจัดการกับ feedback loop ได้เป็นอย่างดีอยู่แล้ว มันจึงเหมาะกับ startups อย่างมากเพราะต้องการความเร็วในการสร้าง และตอบสนองต่อการเปลี่ยนแปลงเพื่อให้เข้าถึง market ที่ต้องการได้
อย่างไรก็ตาม agile ไม่สามารถตอบโจยท์เรื่อง software maturity ได้ดีนัก เพราะบางครั้งโปรเจคไม่สามารถที่จะเริ่มจาก software เล็กๆแล้วค่อยๆเพิ่มของเข้าไปเรื่อยๆได้อย่างต่อเนื่อง บริษัทสาย tech ดังๆที่เติบโต อย่างรวดเร็ว มักจะมี software ที่มี feature ค่อนข้างครบและมีระดับ maturity สูงแล้ว เมื่อ product เข้าใกล้จุดนี้ การเพิ่มอะไรเข้าไปจะเริ่มยากขึ้นและดูเหมือนไม่ค่อยได้เนื้องานอะไร แรงเหวี่ยงที่เคยมีเกี่ยวกับ new feature ก็จะน้อย ในขณะงานส่วนใหญ่จะเป็นการปรับจูนมากกว่า เช่นการปรับ UI หรือการเพิ่ม i18n language support ณ จุดนี้ ทีมงานจะเริ่มเข้าสู่วงจรที่น่าเบื่อ กล่าวคือ ทำมากแต่ได้ value น้อย ซึ่งก็สามารถเป็นต้นเหตของการ burn out ของทีมงานได้ จะเห็นได้ว่า ณ จุดที่ agile เริ่มจะใช้ไม่ได้ผล
เมื่อหลายสิบปีมาแล้ว เราใช้ waterfall methodology ซึ่งยืมมาจากกระบวนการใน manufacturing ที่มีช่วงเวลาที่แยกกันอย่างชัดเจนในการวางแผน, design และลงมือสร้างซอฟต์แวร์ โปรแกรมเมอร์ในยุคถัดมา ไม่ค่อยชอบกระบวนการแบบนี้เท่าไร เพราะความเทอะทะและไม่ตอบสนองต่อการเปลี่ยนแปลงที่รวดเร็ว กว่าจะ release อะไรได้ต้องใช้เวลาเป็นเดือนๆ แทนที่จะเป็นระดับสัปดาห์ การลงทุนลงแรงกับเวลาเป็นเดือนๆโดยไม่มี feedback loop อาจเป็นหายนะสำหรับ startups ที่ต้องเอาตัวรอดด้วยการทำซอฟต์แวร์ที่ตอบโจทย์ตลาดให้รวดเร็วที่สุด
แต่มีบางอย่างใน waterfall model ที่อาจช่วยเราออกจากวงจร sprint cycle ที่น่าเบื่อและเอาเวลาไปดูในส่วนอื่นๆเช่น tech debt ได้ นั่นก็คือ milestone
ใน waterfall นั้น milestone มีไว้เพื่อเป็น deadline ที่แบ่งช่วงเวลาออกจากกันก่อนจะ kickoff อันถัดไป ถ้าเปรียบกับการแข่งขันเรือใบ ใน agile เรายังต้องแข่งรอบถัดๆไป แต่ milestone คือการเข้า finish line หลังจากนั้นทุกอย่างจะหยุด สรุปบทเรียน และเตรียมแข่งต่อใน tournament ถัดไป milestone ทำให้เราตระหนักถึง value ที่เราได้มอบให้ในตัว product และสรุปบทเรียนเพื่อปรับตัวใน phase ถัดไป
จริงๆแล้ว agile ก็มีการสรุปบทเรียนแบบนี้อยู่นะ นั่นคือ retrospective ที่เกิดขึ้นตอนจบ sprint มันเปิดโอกาสให้ทีมได้ทบทวนสิ่งที่เกิดขึ้นหรือไม่เกิดขึ้นใน sprint นั้น แต่บ่อยครั้ง เราก็ละเลยที่จะทำ retrospective อาจเป็นเพราะเวลา หรืองานที่ยัง in-progress ที่เหลืออยู่ก่อนจบ sprint ทำให้ retrospective ถูกมองเป็นภาระ และทำให้พลาดโอกาสในการแก้ไขปรับปรุงกระบวนการทำงานของเรา
ในทางกลับกัน milestone เปิดโอกาสให้เราได้สะท้อนภาพที่ใหญ่กว่า นอก sprint และ focus ไปที่ผลลัพธ์ของตัว product ที่ได้จากหลายๆ sprints ที่ผ่านมา หากทำได้ทุกๆ quarter หรือบ่อยกว่านั้น จะทำให้ การหยุดพักและวางแผน เกิดได้จริง มันอาจกินเวลาแค่ไม่กี่วัน หรือทั้ง sprint เลยก็ได้ เพื่อใช้ในการรวบรวมความคิด แก้ technical debts และวางแผนงานในอีกหลายๆ sprints ถัดไป
บางทีมไม่อาจหาเวลามาทำแบบนี้ได้ง่ายๆ แต่ก็ต้องบอกว่าสิ่งที่สำคัญคือ การหยุด sprint cycle เป็นการช่วยให้เกิดการสะท้อนความเป็นจริงและเรียบเรียงความสำคัญใหม่ เปิดโอกาสให้ทีมงานถามคำถามเช่น ทำไมเราต้องทำ feature นี้? ดังนั้นการทำทั้ง agile iteration และ milestone ควบคู่กันไป จะทำให้เกิดความสมดุลย์ในระยะยาวได้
สรุป
บางครั้งการหยุดพักซักนิดนึงหรือทำอะไรช้าลง จะทำให้เราเห็นสิ่งที่สะท้อนกลับออกมาจากซอฟต์แวร์ที่ครั้งนึง เราอาจเคยคิดว่ามันก็ work ดีอยู่แล้ว การเปิดพื้นที่ให้เราได้มองภาพใหญ่ๆ ของ product หรือ process การทำเช่นนี้ นอกจากช่วยให้ทีมได้มองย้อนกลับไป ยังช่วยชาร์จแบ็ตให้กับทีมงาน เติมพลังให้กลับมาเต็มอีกครั้ง ลดความรู้สึกที่ว่าเวลาผ่านไปแบบซ้ำๆ วนๆไป และเหนืออื่นใด เพื่อเปิดโอกาสให้ทีมได้คิดถึงมุมมองใหม่ๆ ของการพัฒนาซอฟต์แวร์ที่ใช่ ถูกใจลูกค้า