Scrumban ลูกผสมที่ลงตัว
หลังจากที่ทีมพัฒนาทำงานแบบ Scrum มาซักพักหนึ่ง ก็มีการปรับโครงสร้าง แบ่งทีมใหม่ โดยมีการแยกทีมที่ทำงานด้าน Integration & Improvement ออกมาจากทีมที่พัฒนา Feature โดยเฉพาะ ลักษณะการทำงานของทีม Integration & Improvement นี้คือ ในแต่ละ Sprint ก็จะทำงานแก้ Bug ที่มีผลกระทบสูงต่อ User ซึ่งต้องการการตอบสนองที่รวดเร็ว และทำงานพัฒนาเพื่อปรับปรุงคุณภาพ Software ให้ดียิ่งขึ้น แต่เมื่อจะมีการ Release Software ทีมนี้ก็จะทำหน้าที่ Integrate งานจากทีมอื่นๆ ด้วย ซึ่งการทำงานแบบ Scrum ไม่ตอบโจทย์การทำงานของทีมที่มีการเปลี่ยนสูงเช่นนี้ได้อีกต่อไป จึงเป็นที่มาของการทำงานแบบ Scrumban
Scrumban เป็นลูกผสมระหว่างการทำงานแบบ Scrum และ Kanban ในขณะที่ Scrum นั้นมุ่งเน้นการส่งมอบ Software ภายในช่วงเวลาการพัฒนาที่กำหนด ซึ่งเรียกว่า Sprint และมีเป้าหมายในการสร้าง Loop ของการเรียนรู้ ด้วยการได้รับ Feedback ที่รวดเร็วจากลูกค้า ส่วน Kanban นั้นมุ่งที่การพัฒนาประสิทธิภาพของ Flow การทำงาน ตั้งแต่รับงานเข้ามาจนส่งมอบงานอย่างต่อเนื่อง (Continuous Improvement) ด้วยการจำกัด Work in Progress (WIP) โดยใช้ Kanban Board
Kanban นั้นเหมาะกับงานที่ต้องส่งมอบอย่างต่อเนื่อง (Continuous Delivery) ซึ่งการเปลี่ยนลำดับความสำคัญของงานแบบฉับพลันสามารถเกิดขึ้นได้ ในทางกลับกัน Scrum ทำงานตามรอบการทำงานที่มีกำหนดระยะเวลาของ Sprint ที่ชัดเจน ซึ่งมีการจัดลำดับความสำคัญของงานใน Sprint นั้นๆ ไว้แล้วตั้งแต่ต้น เหมาะกับงานที่มีการกำหนด Roadmap ไว้แล้ว และสามารถจัดลำดับความสำคัญของงานได้อย่างชัดเจนตั้งแต่ต้น
เพื่อให้เหมาะกับลักษณะการงานของทีม เราจึงนำข้อดีบางอย่างของทั้ง Scrum และ Kanban มาผสมรวมกันเป็น Scrumban ในแบบของเรา เช่น
การนำวิธีการของ Scrum มาใช้ ได้แก่
· ทำงานตามระยะเวลาที่กำหนดเป็น Sprint ละ 2 อาทิตย์
· Release งานเมื่อจบ Sprint
· มีการกำหนด Role ในการทำงานได้แก่ Product Owner, Scrum Master, Development Team
· มีการทำ Sprint Planning, Sprint Review และ Retrospective
การนำวิธีการของ Kanban มาใช้ ได้แก่
· มีการใช้ Kanban board
· มีการจำกัด WIP ใน Workflow ของงาน
· รองรับการเปลี่ยนแปลง (Change) ที่เกิดขึ้นแบบทันท่วงที
ผลลัพธ์ในการดำเนินงานแบบ Scrumban ค่อนข้างน่าพอใจ เพราะทำให้ทีมมีความคล่องตัวมากกว่าการทำงานแบบ Scrum สามารถรองรับการเปลี่ยนแปลงลำดับความสำคัญของงานได้ทันท่วงที แต่อย่างไรก็ตามทีมยังคงปรับตัวอยู่เสมอเพื่อหาวิธีการทำงานที่เหมาะสมกับทีมต่อไป
References
Dan Radigan, Kanban Overview, 2019:
https://www.atlassian.com/agile/kanban
Max Rehkopf, Kanban Boards, 2019:
https://www.atlassian.com/agile/kanban/boards
Dan Radigan, Wip limits, 2019:
https://www.atlassian.com/agile/kanban/wip-limits
Max Rehkopf, Kanban vs. Scrum, 2019:
