เคยเป็นไหมที่บางครั้งเหมือนเราอยู่กึ่งกลางระหว่าง Scrum กับ Kanban จะไปก็ไปไม่สุด แต่ละ Method มี Limit ที่เราไม่สามารถก้าวข้ามมันไปได้

การทำงานเป็น Vendor ให้กับบริษัทลูกค้า ยิ่งสัญญาเป็น Time and Material แล้ว การที่เราจะไปเปลี่ยนแปลงองค์กรของลูกค้านั้นต้องใช้ทั้ง Effort และค่าใช้จ่าย ในขณะที่ลูกค้าเองก็มองว่าทำไมฉันต้องเปลี่ยนแปลง โดยเฉพาะอย่างยิ่งเวลาที่ทำงานร่วมกับองค์กรที่ไม่ได้อยู่ในแวดวง IT ซึ่งเค้าอาจจะชินกับการทำงานแบบเดิม และไม่มีผลให้ต้องเปลี่ยนแปลง ทำให้ Scrum Team ต้องคอยปรับตัวให้พร้อมกับการเปลี่ยนแปลงแบบ Adhoc ที่เข้ามาเสมอ

ทำให้มันพ่วงมากับปัญหาต่างๆมากมายจากการใช้ Scrum ในเคสนี้ เช่นทำไมมีงานแทรกกลางสปริ้นตลอด, ทีม Lost Focus, บางครั้งมีการ Rework บ่อยครั้ง, และไม่สามารถจบ DOD ได้เพราะต้องรอการ Approve จากผู้บริหารก่อน

_{source: Nuntikarn (MAQE)}

พอเกิดเคสนี้ขึ้นในหลายๆ ครั้งใน Project มันก็เกิดคำถามขึ้นว่า หรือเราไม่เหมาะกับ Scrum…

มาลองเข้าใจ Scrum กันใหม่อีกสักตั้ง

Scrum Framework เหมาะกับโปรเจคที่เราจะเติบโตไปกับมันทั้ง Process และ Product รวมถึงพร้อมรับการเปลี่ยนแปลงและปรับตัวเสมอในทุกๆสปริ้น รวมถึงการ Enhance Product ในระยะยาว รับ Feedback และพร้อมแก้ไขให้เหมาะกับตลาดอยู่เสมอ

ดูทรงแล้วก็น่าจะเวิร์คนี่นา แต่…

Scrum ทำงานเป็นสปริ้น แต่ละสปริ้นจะมี Goal ที่ชัดเจน ทีมจะ Focus กับ Goal แล้วส่งมอบงานเมื่อจบสปริ้นที่ตกลงไว้เท่านั้น เพื่อให้ทีมสามารถ Focus ได้ชัดเจน แต่ปัญหาที่ตามมาของ Vendor คือถ้า Direction ของ Product ไม่ชัดเจน และมีการเปลี่ยนแปลง Requirement บ่อยๆ จะทำให้มีงานแทรกกลางสปริ้นและอาจต้องเบรคสปริ้นตลอด ซึ่งถึงต่อให้ใช้เป็นสปริ้น 1 วีค ระยะเวลาก็น้อยเกินกว่าจะพัฒนางานออกมาเป็นชิ้นเป็นอันในสปริ้นได้ และอาจทำให้เกิด Gap จาก DOD ตั้งแต่เริ่มงานจนส่งมอบงานถึงมือลูกค้าได้สำเร็จ และทีมต้องมาคอยเก็บ Gap ที่ต้องมาทำ sprint UAT หรือ sprint deployment ตรงนี้ด้วย ซึ่งก็อาจจะผิดหลักของ Scrum ไปได้

รวมถึง Scrum นั้นยังไม่เหมาะกับการที่ต้องทำงานร่วมกับทีมที่ยังทำงานด้วยรูปแบบเก่าๆ อย่างเช่นที่กล่าวไว้ตอนต้น เมื่อลูกค้าไม่สามารถเปลี่ยนการทำงานให้เหมาะสมกับ Scrum ได้ ทีม Scrum เองก็จะต้อง manage priority และ design software ให้มีความหลากหลายมากๆ

_{Source: https://pmprotocol.blogspot.com/2015/02/scrum-issue-08-product-owner-cant.html}

แล้ว Kanban ล่ะ จะเหมาะกับการทำงานแบบ Vendor รึเปล่านะ…

มาเข้าใจ Kanban กันก่อน Kanban เหมาะกับทีมที่มีความยืดหยุ่นสูง และสามารถปรับใช้ได้กับทุก Workflow เพื่อให้การทำงานมีประสิทธิภาพ พร้อมทั้งยังสามารถจำกัด Work in Progress และทำให้มี Transparent มากขึ้น แถมยังเหมาะกับการเปลี่ยน Priority งานกลางทางได้อย่างเหมาะสมอีกด้วย ทำให้งานของ Kanban นั้นสามารถส่งมอบงานได้อย่างต่อเนื่อง

_{Source: https://www.agilesparks.com/limiting-work-in-progress-wip-some-anecdotes-worth-thinking-about-when-using-kanban-with-scrum/}

เอ..ดูๆทรงแล้วก็น่าจะใช้ได้นี่นา

แล้วทำไมไม่ใช้ Kanban ล่ะ ซึ่งถ้าลองมาดูจริงๆ Kanban นั้นเหมาะกับองค์กรที่มี Process อยู่แล้ว แต่บังเอิ๊ญเคสนี้ดันทำงานร่วมกับลูกค้าที่อยู่กันคนละองค์กรทำให้มี Process ที่ต่างกันและที่สำคัญ Kanban ยังไม่เหมาะกับการที่ต้อง Enhance Software ใหญ่ๆ หรือที่ต้อง Maintain ยาวๆ อีกด้วย เพราะว่า…

• Kanban เหมาะกับงานที่มีมาด้วย Size ที่เท่าเดิม และเป็นงานที่ทำซ้ำๆ คล้ายๆเดิม เช่นงาน Support จึงไม่เหมาะกับงาน Implement ที่มีหลาย Size, มีความหลากหลายในตัวเอง เพราะงั้นถ้าต้องมีการเปลี่ยน Requriement บ่อยๆ หรือ Vary มากๆ จะสร้างปัญหาให้ Kanban Workflow แน่นอน
• Kanban เหมาะกับงานที่โดนแพลนมาล่วงหน้าอย่างดีแล้วไม่เหมาะกับงานที่ต้อง deploy บ่อยๆ หรือถี่ๆตลอดเวลา หรือ product ที่มี demand สูงๆ เพราะจะส่งผลต่อ quality ของ product
• Kanban ไม่เหมาะกับงานที่มีความเสี่ยง หรือ อะไรที่ต้องทำ Proof of Concept (POC) ก่อน เพราะ Kanban มี WIP อย่างชัดเจน หากต้องมีงานที่ต้อง POC ก่อนจะทำให้ Kanban ไม่ flow ได้

จากเหตุด้านบน ถ้าเราอยู่ในสถานการณ์ที่ต้องทำการ Maintain Software ใหญ่ๆ อาจจะไม่เหมาะ ยิ่งต้องทำงานร่วมกับลูกค้าจึงไม่เหมาะจะใช้ Kanban เพียวๆเลย

_{Source: https://memegenerator.net/instance/68190306/psy-oppa-kanban-style}

ถ้า Scrum ก็ไม่ได้ Kanban ก็ไม่เหมาะ แล้วเราจะทำยังไงดีนะ…

เมื่อเริ่มมาลองหาเกี่ยวกับ ScrumBan

เอาจริงๆ แล้วก็อยากได้ความ Flexible ของ Kanban และอยากได้ Structure ของ Scrum ก็เลยลองมานั่งๆ Research ไปเรื่อยๆ ก็ไปเจอกับ Framework ตัวนึงเข้า ที่มีชื่อว่า ScrumBan

น่าสนใจเลยทีเดียว ScrumBan เป็นการรวมข้อดีระหว่าง Scrum กับ Kanban โดยการนำเอา Structure ของ Scrum และความ Flexible ของ Kanban มารวมอยู่ด้วยกัน ทำให้เกิด Hybrid Framework ซึ่งหากใช้งานอย่างถูกวิธี จะสามารถดึงเอาความลงตัวและจุดเด่นของทั้งสอง Framework มาใช้งาน ซึ่งทำให้ดึงข้อดีจากการวางแผนที่ดีของ Scrum และอิสระในปรับปรุง Flow และ Process ของ Kanban มาประยุกต์ใช้งานร่วมกันได้อีกด้วย

_{Source: https://www.researchgate.net/figure/Agile-Scrumban-in-the-Kampus-merdeka-learning-system_fig2_349147683}

ScrumBan ทำงานยังไง

1. ScrumBan จะใช้ Board แบบเดียวกับ Kanban Board ทีมสามารถ Setup Workflow ในแบบที่ทีมต้องการได้เลย
2. เริ่ม Set WIP (Work in Progress) การ Set limit ในแต่ละเลนบน Board ว่าทีมรับได้แค่ไหน สำหรับ ScrumBan จะใช้ Backlog ทั้งหมดที่อยู่บน Board จะถือว่าเป็น Limit ที่ทีมจะรับไหว
3. จัดเรียงความสำคัญของงานให้ทีมแต่ละคน ทีมจะเป็นคนตัดสินใจว่าใครจะดูแล Task ไหนยังไง และจัดเรียงความสำคัญของงานที่เข้ามาทำแทนที่จะรอให้ PM หรือ PO มาเป็นคนจัดการ
4. ด้วย Scrum Framework ทีมจะทำงานได้อย่างต่อเนื่องและไม่มีข้อจำกัด เพราะทีมไม่ต้องกังวลเรื่องการประเมิน Story Points ทีมงานจะ Focus เฉพาะงานที่สำคัญๆ เท่านั้น

_{Source: https://kanbantool.com/scrumban}

Scrumban ช่วยอะไรเราได้บ้าง

1. ScrumBan เหมาะกับ Large-scale Project, Maintain ระยะยาว, มีความ Complex และใช้เวลานาน เพราะตัว Process นั้นมาพร้อมกับความสามารถในการสนับสนุนแพลนในระยะยาว
2. ScrumBan ช่วยประหยัดเวลาและมีประสิทธิภาพ เมื่อเรา Implement ScrumBan ตัวของ ScrumBan จะช่วยให้เราทำงานได้อย่างมีประสิทธิภาพมากขึ้น เพราะทีมจะมีเวลาในการทำงานมากขึ้น เช่น ทีม ScrumBan จะมี Planning เมื่อทีมต้องการเท่านั้น มากกว่านั้นทีมไม่จำเป็นต้องใช้เวลาไปกับการทำ Daily Standup และ Event อื่นๆ ทำให้ทีมสามารถใช้เวลาในการพัฒนา Software ได้อย่างเต็มในการ Focus งาน
3. ScrumBan ใช้งานได้ง่าย ส่วนนี้ได้มาจาก Kanban ที่สามารถเริ่มใช้ได้ง่าย และมีความ Flexible สูง
4. ScrumBan ช่วยเพิ่มความยืดหยุ่นในการทำงานมากยิ่งขึ้น เพราะ ScrumBan จะไม่ได้มี Sprint Backlog Fix ไว้ในแต่ละสปริ้น แต่จะลิส Backlog ทั้งหมดเรียงตาม Priority ทำให้ทีมสามารถกำหนด Capacity ในการทำแต่ละ Backlog ได้
5. ScrumBan สามารถช่วยในการลด Waste และ ลด Lead time ในการทำงานทั้งหมดได้ด้วย

_{Source: https://www.leanmemes.com/2014/05/do-you-want-to-build-kanban-song-parody.html}

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

ข้อจำกัดของ Scumban

1. ในบางครั้ง Scumban นั้นยากที่จะรับมือ เนื่องจาก Scumban นั้นค่อนข้างใหม่และยังไม่เสถียรพอ ทำให้หลายๆคนยังไม่รู้ถึงวิธีใช้งานมันได้ดี หรือในกรณีที่มีปัญหาจะรับมืออย่างไร และตัว Framework นี้ก็ยังไม่มี Best Practise ที่ดีที่สุด ว่าง่ายๆใครอยากนำไปใช้ก็ต้องคอย Adapt กันเอง ให้เหมาะสมกับหลักของ Agile
2. Scumban ไม่มี Tracking Process ที่ดี เพราะไม่มีทั้ง Standup หรือ Sprint Planning ทำให้ถ้าไม่ลงไปดูใน Board หรือเข้าไปคลุกคลีกับทีมจะไม่รู้เลยว่าทีมกำลังทำอะไรอยู่ หรือว่าสถานะเป็นยังไง และไม่มีตัววัด Capacity และ Velocity ของทีมเช่นกัน

ทิ้งท้ายไว้… ไม่ว่าจะเป็น Scrum, Kanban และ Scrumban จะมีข้อดีข้อเสียแตกต่างกันไป เพราะงั้นเราควรเลือกใช้ Methodology ให้เหมาะกับสถานการณ์ และคอยคำนึงถึง Limitation และความต้องการของทีมด้วย และการ Implement ในทุกๆ Agile Framework ที่ใช้ อย่าลืมคำนึงถึงหลัก Agile Manifesto ด้วย ไม่งั้นได้กลายเป็น Mini Waterfall แน่ๆ

บทความนี้เป็น Tech Saucier โดย Nuntikarn 'Book' Sakunrungjarus (MAQE)