โครงสร้างทีมแบบ Agile: บทบาทและความรับผิดชอบเพื่อความสำเร็จ

ประเด็นสำคัญ

ลักษณะที่ยืดหยุ่นของ Agile

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

Agile เป็นวิธีการ ไม่ใช่ระเบียบวิธี

Agile ตั้งอยู่บนหลักการที่อธิบายไว้ใน Agile Manifesto เช่น:

1. การปรับตัวต่อการเปลี่ยนแปลง
2. การร่วมมือกับลูกค้า
3. การปรับปรุงอย่างต่อเนื่อง

Agile เป็นปรัชญา ไม่ใช่ชุดคำสั่ง ทีมที่ทำงานในนั้นเลือกการนำไปปฏิบัติ — Scrum, Kanban, SAFe — ตามประเภทงานที่ทำและระดับการประสานงานที่ต้องการ การเลือกการนำไปปฏิบัติผิดไม่ได้ทำให้ทีม "ไม่ Agile"; โดยปกติเพียงสร้างแรงเสียดทานที่ทำให้สิ่งที่ Agile ควรเร่งให้เร็วขึ้นช้าลง

Scrum ในฐานะการนำไปปฏิบัติ Agile ที่ได้รับความนิยม

Scrum เสนอทีมที่มีโครงสร้างแบ่งเป็นสามบทบาทหลัก:

1. Product Owner: จัดการ backlog กำหนดลำดับความสำคัญของงาน
2. Scrum Master: อำนวยความสะดวกกระบวนการ ขจัดอุปสรรค
3. ทีม: กลุ่มที่จัดระเบียบตัวเองที่ทำงานสปรินต์ให้เสร็จ

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

โครงสร้างทีม Agile สนับสนุนการทำงานร่วมกันอย่างไร

1. การข้ามสายงาน: สมาชิกในทีมครอบคลุมศาสตร์เพียงพอที่จะย้ายงานจากต้นจนจบโดยไม่ต้องรอทีมภายนอก ยิ่งส่งมอบน้อย ยิ่งเวลาในรอบสั้น
2. การจัดระเบียบตัวเอง: ทีมตัดสินใจว่าจะเข้าหางานอย่างไร — ผู้จัดการกำหนดทิศทาง ไม่ใช่วิธี ลดคอขวดของห่วงโซ่อนุมัติในการตัดสินใจประจำวัน
3. กระบวนการแบบวนซ้ำ: retrospectives เป็นประจำสร้างวงจรข้อเสนอแนะที่จับปัญหากระบวนการก่อนที่จะทบกันข้ามสปรินต์

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

การปรับทีม Agile ให้เข้ากับโครงการที่แตกต่างกัน

โครงสร้าง Agile ยืดหยุ่นและเปลี่ยนไปตามประเภทและขนาดของโครงการ ตัวอย่างเช่น:

ใน Kanban ไม่มีบทบาทคงที่ — ทีมมุ่งเน้นการแสดงเวิร์กโฟลว์และจำกัดงานที่กำลังดำเนินแทนที่จะจัดการรอบสปรินต์

ใน SAFe (Scaled Agile Framework) บทบาทกลายเป็นชั้นเชิงมากขึ้นเพื่อประสานงานหลายทีมที่ทำงานเพื่อบรรลุวัตถุประสงค์โปรแกรมที่แบ่งปันกัน

เพื่อเจาะลึกหัวข้อ Agile และ Scrum เริ่มต้นด้วยบทความ "Agile Manifesto คืออะไร? ทำความเข้าใจค่านิยมและหลักการสำคัญ" ที่ครอบคลุมพื้นฐาน จากนั้นไปที่ "Scrum Master คืออะไร? บทบาทและความรับผิดชอบหลักที่อธิบายไว้" เพื่อทำความเข้าใจบทบาทสำคัญของทีมนี้ 

บทสรุป

โครงสร้างทีม Agile ใช้งานได้เพราะวางความรับผิดชอบไว้ที่ที่งานเกิดขึ้นจริง องค์ประกอบข้ามสายงานลดการรอ การจัดระเบียบตัวเองตัดค่าใช้จ่ายในการอนุมัติ Retrospectives ป้องกันหนี้กระบวนการไม่ให้สะสมโดยเงียบ กรอบเฉพาะ — Scrum, Kanban, SAFe — สำคัญน้อยกว่าว่าทีมมีความเป็นเจ้าของที่ชัดเจน วงจรข้อเสนอแนะที่สั้น และอำนาจในการปรับวิธีการทำงานของพวกเขาหรือไม่

การอ่านที่แนะนำ

"Scrum: The Art of Doing Twice the Work in Half the Time"

อธิบายวิธีเพิ่มผลผลิตผ่านการพัฒนาแบบวนซ้ำและวิธีการที่อิงกับทีมในองค์กรใดๆ

"Agile Project Management with Kanban"

แสดงวิธีปรับปรุงการไหลของโครงการและการส่งมอบโดยใช้ระบบการจัดการแบบภาพของ Kanban

"The Lean Startup"

นำเสนอวิธีการสร้างธุรกิจที่ประสบความสำเร็จผ่านการทดสอบที่รวดเร็วและความคิดเห็นของลูกค้า