ไม่นานมานี้ผมเพิ่งจบโปรเจกต์กับลูกค้าที่สร้าง product ด้วยกันมานานเกือบสองปี มีหลายเรื่องที่อยากมาแชร์ให้ฟังครับ ระหว่างทางมีโอกาสได้ลองวิธีการทำงานหลายแบบ ทั้งแบบ Iterative ด้วย Scrum หรือแบบ Continuous ด้วย Kanban เพื่อปรับตัวเข้ากับ challenge ต่างๆ และ priority ที่ไม่แน่นอน รวมถึงทีมที่มีการเปลี่ยนแปลงตลอดเวลา
Scrum ถือว่าเป็นหนึ่งใน framework ที่นิยมที่สุดสำหรับ Agile และมักจะถูกใช้โดยหลายบริษัทที่อยากทำงานแบบ Agile ในช่วงแรกเริ่มของโปรเจกต์ เราเริ่มต้นได้ดีด้วย Scrum แต่พอโปรเจกต์เดินหน้าไปเรื่อยๆ ก็เริ่มพบปัญหาต่างๆ ที่ต้องปรับให้เหมาะกับสถานการณ์
สรุปข้อคิดสำคัญ
- ทุกบริษัทมีข้อจำกัดที่แตกต่างกันไป ไม่ว่าจะเป็นเรื่องวัฒนธรรมองค์กร กระบวนการทำงาน หรือความสำคัญ ที่อาจจะไม่เอื้อให้ทำตามหลัก Agile ในอุดมคติของหลายๆ คนได้
- Scrum ไม่ใช่สิ่งที่สามารถแก้ปัญหาทุกอย่างได้ มันเป็นแค่ framework หนึ่งที่ใช้ได้ดีกับบางสถานการณ์
- การที่เราเลิกใช้ Scrum ไม่ได้หมายความว่าเราล้มเหลวในการทำงานแบบ Agile กลับกันมันคือสัญญาณของการปรับตัวและเรียนรู้
บริษัทยักษ์ใหญ่เติบโตจากโครงสร้าง
องค์กรขนาดใหญ่มักมีกระบวนการต่างๆ เช่น การจัดการทรัพยากร ความปลอดภัย การปฏิบัติตามข้อกำหนด และกระบวนการทำงานหลายขั้นตอน ที่อาจทำให้รู้สึกน่าหงุดหงิด แต่ทั้งหมดนี้ก็มีเหตุผลของมันอยู่ เพื่อสร้างความมั่นคง ปกป้องข้อมูลสำคัญ และทำให้องค์กรสามารถทำงานได้อย่างมีประสิทธิภาพ
สำหรับทีม Agile ข้อจำกัดเหล่านี้บางครั้งอาจดูขัดแย้งกับหลักการสำคัญของความยืดหยุ่นและการส่งมอบงานอย่างรวดเร็ว ยกตัวอย่างเช่น:
- การแยก UAT Phase ออกต่างหาก ทำให้ feedback loops ล่าช้า และกระบวนการ Iterative ถูกขัดจังหวะ
- ตารางการ Release ที่เข้มงวด ทำให้การอัปเดตหรือเผยแพร่งานบ่อยๆ เป็นเรื่องยาก และจำกัดการส่งมอบ value ให้ผู้ใช้แบบต่อเนื่อง
- ความห่างไกลจากลูกค้าจริง ขั้นตอนที่มีหลายชั้นและกฎเกณฑ์ที่เข้มงวดทำให้ยากต่อการเก็บ feedback จากผู้ใช้งานจริง ซึ่งเป็นสิ่งสำคัญในการปรับปรุง product
เป็นธรรมดาที่เราจะรู้สึกขัดใจกับหลายๆ สิ่งที่มันอยู่เหนือการควบคุมของเรา แต่การเข้าใจว่า “ทำไม” ขั้นตอนหรือกฎเหล่านี้ถึงเกิดขึ้น จะช่วยปรับความคาดหวังให้ตรงกัน และหาวิธีทำงานให้มีประสิทธิภาพในระบบนั้นได้ ท้ายที่สุดแล้ว โครงสร้างเหล่านี้คือสิ่งที่ทำให้บริษัทเหล่านี้เติบโตและประสบความสำเร็จ พร้อมสร้างความมั่นคงและความเชื่อมั่นในระดับใหญ่ การบาลานซ์ระหว่างความคล่องตัวกับกระบวนการที่มีอยู่ไม่ใช่แค่เป็นไปได้ แต่เป็นสิ่งสำคัญสำหรับการทำงานพัฒนาในบริบทขององค์กร
การบาลานซ์ความคล่องตัวกับโครงสร้างองค์กร
เพื่อปรับตัวให้เข้าความท้าทายเหล่านี้ PALO IT ได้ปรับวิธีการทำงานของเราผ่าน 3 ช่วงหลักๆ โดยปรับเปลี่ยนโมเดลการทำงานให้ตอบโจทย์ความท้าทายต่าง ๆ รับฟัง feedback และตอบสนองต่อความต้องการในขณะนั้น
Phase 1 — เริ่มต้นด้วย Scrum
เราเริ่มโปรเจกต์ด้วยการทำงานแบบ Scrum ตามปกติ โดยใช้ sprint สองสัปดาห์ แต่ไม่กี่เดือนหลังเริ่มพัฒนา เราเจอปัญหาใหญ่ นั่นก็คือเราไม่สามารถดึงผู้ใช้งานจากฝั่ง business มาเข้าร่วมในกระบวนการพัฒนาได้ การขาดการมีส่วนร่วมนี้กลายเป็นต้นเหตุของ expectation ที่ไม่ตรงกัน และสุดท้ายเราจำเป็นต้องปรับวิธีการทำงานในช่วงถัดไป
แม้จะไม่ได้ลงลึกในรายละเอียดปัญหานี้ แต่ข้อคิดสำคัญคือ ความยืดหยุ่นเมื่อเจอความท้าทาย การปรับเปลี่ยนวิธีการทำงานเป็นสิ่งจำเป็น เพื่อให้ตอบโจทย์ความต้องการของโปรเจกต์และความคาดหวังของลูกค้าได้อย่างมีประสิทธิภาพ
Phase 2 — ลดช่องว่างด้วย sprint หนึ่งสัปดาห์
เมื่อเข้าสู่ช่วง User Acceptance Testing (UAT) ช่องว่างระหว่างความคาดหวังของผู้ใช้งานฝั่ง business และ product ที่เราพัฒนาก็เริ่มชัดเจน ช่องว่างเหล่านี้ที่มักถูกเรียกว่า “Bug” สะท้อนถึงความเข้าใจผิดที่สะสมมา เราจึงตัดสินใจให้ความสำคัญกับ feedback loops ที่รวดเร็วยิ่งขึ้น โดยปรับลด sprint ให้เหลือหนึ่งสัปดาห์
การเปลี่ยนแปลงนี้ช่วยให้ทีมสามารถโฟกัสทั้งการพัฒนา feature ใหม่และการแก้ไขปัญหาที่พบ ด้วยลำดับความสำคัญที่เปลี่ยนแปลงอย่างต่อเนื่องในช่วงนี้ ที่มาจาก feedback ของผู้ใช้และความต้องการที่เปลี่ยนไป ลูกค้าจึงพบว่าการวางแผนล่วงหน้าเกินกว่าหนึ่งสัปดาห์เป็นเรื่องยาก การใช้ sprint ที่สั้นลงช่วยให้เราปรับเป้าหมายได้เร็ว และส่งมอบงานเป็นขั้นตอนได้อย่างมีประสิทธิภาพมากขึ้น
Phase 3 — เตรียม Release ด้วย Kanban
เมื่อใกล้ถึงช่วงปล่อย product ให้ผู้ใช้งานจริง ลักษณะของงานก็เปลี่ยนไปอีกครั้ง ขั้นตอนสำหรับการ release เช่นการทดสอบความปลอดภัย การทดสอบเจาะระบบ และการอนุมัติหลายขั้นตอน ทำให้เกิดงานเฉพาะหน้าจำนวนมากที่ต้องได้รับการจัดการทันที นอกจากนี้ ทีมยังต้องทำ feature เล็กๆ ไปพร้อมกันด้วย
เพื่อจัดการกับงานที่ทั้งวางแผนไว้ล่วงหน้าและเกิดขึ้นเฉพาะหน้า เราเปลี่ยนมาใช้ Kanban เพื่อที่จะยกเลิกข้อจำกัดของ sprint ที่มีกรอบเวลา การเปลี่ยนแปลงนี้ช่วยให้ทีมสามารถโฟกัสที่การทำงานให้เสร็จลุล่วงตามความต้องการที่เกิดขึ้น ช่วยให้กระบวนการปล่อยงานราบรื่นยิ่งขึ้น ในขณะที่ยังสนับสนุนความต้องการสำคัญของโปรเจกต์ได้อย่างเต็มที่
Iterative vs. Continuous Flow Development: เลือกให้เหมาะกับโปรเจกต์
หลังจากผ่านทั้งสามช่วงของโปรเจกต์ เราได้เรียนรู้ว่า การเลือกระหว่างการพัฒนาแบบ Iterative และ Continuous Flow ขึ้นอยู่กับลักษณะของโปรเจกต์นั้นๆ ในช่วงแรก sprint ของ Scrum นั้นเหมาะกับการทำงานของเรา เนื่องจากมีโครงสร้างชัดเจนและมี milestone ให้ติดตาม แต่เมื่อเจอความท้าทายใหม่ๆ เราต้องการความยืดหยุ่นมากขึ้น Continuous Flow development จึงเหมาะสมกว่าในช่วงที่เราต้องปรับตัวเข้ากับลำดับความสำคัญที่เปลี่ยนแปลงและข้อจำกัดจากภายนอก
ข้อดีของ Iterative Development
การพัฒนาแบบ Iterative เหมาะสำหรับโปรเจกต์ที่ได้ประโยชน์จากการมี checkpoint เป็นระยะ ๆ และความรู้สึกของการทำงานที่เสร็จเป็นรอบๆ
- การวางแผนและการสื่อสาร:
การพัฒนาแบบ Iterative ช่วยให้วางแผนและสื่อสาร timeline ได้ง่ายขึ้น ทำให้ผู้มีเกี่ยวข้องรับรู้ถึงความคืบหน้าและปรับลำดับความสำคัญได้
- โฟกัสและการทำงานร่วมกัน:
การกำหนดกรอบเวลาแบบ timeboxed ของ Sprint ช่วยให้ทีมโฟกัสกับงานตรงหน้า และส่งเสริมการทำงานร่วมกันและรับผิดชอบร่วมกัน
- Milestone และ Teamwork:
รอบ Sprint ที่สม่ำเสมอจะช่วยสร้าง milestone ที่ชัดเจน และมีจังหวะให้ทีมได้รู้สึกถึงความสำเร็จเมื่อจบแต่ละ Sprint ช่วยให้ทีมเห็นความคืบหน้าของ product และเพิ่มความเป็นส่วนหนึ่งของทีม
เมื่อไหร่ที่ควรใช้ Continuous Flow Development
- งานมีเข้ามาเรื่อย ๆ และไม่สามารถคาดเดาได้:
เมื่องานเข้ามาเรื่อย ๆ ทีมต้องการความยืดหยุ่นในการปรับการทำงานโดยไม่กระทบกับ cycle ที่วางแผนกันไว้
- ความยืดหยุ่นคือสิ่งสำคัญ:
เมื่อความลำดับความสำคัญถูกเปลี่ยนบ่อย Continuous Flow สามารถทำให้ทีมปรับการทำงานได้อย่างรวดเร็วโดยไม่ต้องรอให้จบ Sprint
- ไม่ได้ต้องการ timeline ที่แน่นอน:
เมื่อไม่มี milestone หรือ deadline ที่แน่นอน Continuous Flow ทำให้งานถูกหยิบเรื่อย ๆ โดยไม่ได้ถูกกดดันด้วย sprint deadlines
ความยืดหยุ่นคือหัวใจของความสำเร็จ
สุดท้ายแล้ว ข้อคิดสำคัญคือ Agile เป็น mindset ที่ยืดหยุ่น ไม่ใช่กรอบการทำงานที่ตายตัว ตลอดสามช่วงของโปรเจกต์ เราได้เรียนรู้ว่า การปรับ Agile ให้เหมาะกับความต้องการของโปรเจกต์ รวมถึงข้อจำกัดในองค์กรขนาดใหญ่ไม่ใช่แค่เรื่องจำเป็น แต่เป็นกุญแจสำคัญของความสำเร็จ ไม่ว่าจะเป็นการพัฒนาแบบ Iterative หรือ Continuous Flow ความสามารถในการปรับเปลี่ยนและพัฒนาวิธีการทำงานตามความต้องการของโปรเจกต์ คือสิ่งที่ช่วยให้เราทำงานได้อย่างมีประสิทธิภาพที่สุด
พร้อมที่จะมาร่วมประสบการณ์การทำงานแบบ Agile กับเราหรือยัง?
หากองค์ของคุณต้องการที่จะเริ่ม หรือรู้สึกว่ายังปรับใช้การทำงานแบบ Agile ได้ไม่ค่อยมีประสิทธิภาพ สามารถมาปรึกษากับทาง PALO IT ได้ครับ เรามีผู้เชี่ยวชาญด้าน Agile ที่ได้รับ ICAglie Certified Professional พร้อมที่จะช่วยสร้างกระบวนการพัฒนาที่มีความยืดหยุ่น และมีประสิทธิภาพมากขึ้นได้ครับ
.png)
