Scrum ติ๊กถูก
หากว่าเรากำลังสบายมาทำScrum แปะๆ
หากว่าเรากำลังสบายมาทำScrum แปะๆ
เมื่อองค์กรณ์คุณคิดจะเริ่มทำ Agile จะมีคนบอกว่าทำ Scrum สิ และคุณก็เริ่มไปเรียน Scrum และ คุณก็เริ่มทำ Scrum และคุณก็เป็น Scrum
อ้าว และเราจะเป็น Scrum ยังไงนะ อ๋อออออออ งั้นเราเปิดหนังสือ Scrum ดูดีกว่า
- Scrum Team ต้องมีใครนะ
1. Product Owner (PO) 1 คน : อ๋ออ เรายังไม่มี PO งั้นเราเอา BA มาเป็น PO ดีกว่านะ ไม่เป็นไรหรอก เพราะ BA ปรกติก็ทำเรื่อง Requiremnt อยู่แล้วไง
2. ScrumMaster 1 คน : อ๋อออ ต้องมี SM ใช่ไหม งั้นเอา PM มาเป็นก่อนแล้วกันมันน่าจะมีหน้าที่คล้ายๆ กัน เดี๋ยวส่งไปเทรนเอา Certificat สักหน่อย
3. Development Team 5–9 คน : อันนี้ง่ายแล้ว เอาน้องๆ Dev มาเลย
เอ้า…ติ๊กถูก
2. Scrum ต้องมี 6 พิธีกรรม
1. Sprint Planning Part I
2. Sprint Planning Part II
3. Daily Scrum
4. Product Backlog Refinement
5. Sprint Review
6. Sprint Retrospective
โอเคงั้นพวกเรามา Setup meeting จัดกันเองใน IT นะว่าพวกเรามีแล้ว
เอ้า…ติ๊กถูก
3. แล้วสิ่งสำคัญคือเราต้องมี SCRUM Board นะ งั้นพวกเรามาทำบอร์ดกัน นะ
เอ้า…ติ๊กถูก
โอเคมาถึงตรงนี้เราเป็น Scrum แล้ว พวกเราประสบความสำเร็จแล้วหละ ฉลองงงงงงงงงงงงง
หยุด!!! คิดดีๆ ครับ เรากำลังทำ Scrum เพื่อเป็น Scrum หรือ เป้าหมายเราจริงๆ คือ เรากำลังทำ Scrum เพื่อเป็น Agile
อยากให้กลับมาย้อนคิดกันครับว่าเราเอา Scrum เข้ามาทำเพื่ออะไรกันนะ เรากำลังทำเพื่อเปลี่ยนแปลงการทำงานของเราให้เป็น Agile ใช่ไหมครับ
แนวคิดสำคัญของ Agile
คนและการมีปฏิสัมพันธ์กัน →มากกว่าการทำตามขั้นตอนและเครื่องมือ
ซอฟต์แวร์ที่นำไปใช้งานได้จริง →มากกว่าเอกสารที่ครบถ้วนสมบูรณ์
ร่วมมือทำงานกับลูกค้า →มากกว่าการต่อรองให้เป็นไปตามสัญญา
การตอบรับกับการเปลี่ยนแปลง →มากกว่าการทำตามแผนที่วางไว้
ทั้งนี้ แม้เราจะเห็นความสำคัญในสิ่งที่กล่าวไว้ทางด้านขวา
แต่เราให้ความสำคัญกับสิ่งที่กล่าวไว้ทางด้านซ้ายมากกว่าทั้งนี้ แม้เราจะเห็นความสำคัญในสิ่งที่กล่าวไว้ทางด้านขวา
แต่เราให้ความสำคัญกับสิ่งที่กล่าวไว้ทางด้านซ้ายมากกว่า
ซึ่งการเราเอา Scrum มาใช้ก็เพื่อตอบโจทย์การเป็น Agile และโดยส่วนใหญ่จะเร่ิมทำกันใน IT และก็เอาคนใน IT เนี้ยแหละมาลง role ให้ครบการเป็น Scrum มันไม่ผิดนะครับเป็นการเริ่มต้นที่ดี แต่อยากให้มองภาพด้วยว่าการทำแบบ Scrum ไม่ได้มีแค่ Delivery Loop แค่อย่างเดียว สิ่งที่สำคัญอีกส่วนคือ Discovery Loop ลองดูรูปสองรูปข้างล่างครับ
จะเห็นว่าถ้าเราทำ Scrum กันแค่ IT เราจะให้ความสำคัญกับการ Delivery และเราอาจจะแค่ทำการเปลี่ยน Business Requirement Document (BRD) มาย่อยๆ เป็น Story โดยให้ BA มาเป็นคนทำ แค่เดินไปหา User นิดหน่อย แล้ว BA เนี้ยแหละก็มากำหนด Pioroty แล้วให้ทาง Dev ทำ SM ที่เคยเป็น PM มาก่อนและได้ทำการเรียน Scrum มาแล้วก็เริ่มให้ทีมเริ่มทำกระบวนการ Scrum ทันทีและพยายามให้มีการส่งมอบได้เร็ว ถ้ามี Bug ก็เอามา Add ลง Backlog ฟังดูก็เหมือนจะดีใช่ไหมครับ?
แต่เราขาดอะไรไปครับ……ใช่ครับเราขาดฝั่ง Business ครับ เราขาดการมอง Business Value ที่จะส่งมอบของให้กับ Real Customer เราขาดการทำ Discover ครับ ลองดูภาพข้างล่างนะฮะ ว่ามันมีความสมเหตุสมผลของทั้งสองส่วน
มันเริ่มมาจาก Product ที่เราจะทำควรมองมาจากทั้งสามแกนหลังดังภาพนี้ครับ
และจากการรวมพลังกับของทั้งทีมมันคือ Product เราที่อยู่ตรงกลางวงกลมทั้งสามดังภาพ
ซึ่งถ้ามองภาพเป็นการทำงานแบบ Scrum ก็จะมี Level ดังภาพนี้ครับ จะเห็นได้ว่ามีการเริ่มตั้งแต่ Ideas ซึ่งอาจจะมาจาก Business ระดับผู้บริหาร และลงมาสู่ทีมที่มีทั้ง Business และ Technical รวมมือกัน รวมหัวกันเอาไอเดียนั้นมาก่อร่างสร้างภาพออกมาเป็น MVP ในกระบวนการของ Discovery และสุดท้ายหลังจากนั้นเราก็ทำการส่งมองไปให้ทีม Dev Delivery สิ่งนั้นออกมา
จะเห็นได้จากภาพด้านล่างนี้ชัดขึ้นในการทำงานของทั้งสอง Loop เป็น Sprint
และสุดท้ายในภาพใหญ่เมื่อเรามีการทำงานทั้งสอง Loop จริงๆ มันก็จะมีการประสานทั้งสองวงกลมเป็น Infinity loop ดังภาพล่างนี้ครับ
เห็นไหมครับว่าการทำ Scrum เพื่อให้เป็น Agile เราทำเองเฉพาะ IT ไม่ได้หรอกครับ อยากแนะนำว่า เมื่อเราจะเริ่มทำให้มีการพูดคุยกับทั้งองค์กรณ์เพื่อนำการเปลี่ยนแปลงนี้ไปสู่ทั้งองค์กรณ์ไม่ใช่แค่ฝ่ายใด ฝ่ายหนึ่ง เพราะการส่งมอบ Product ให้ลูกค้า ไม่มีทางที่จะทำได้โดยใช้เพียงฝ่าย IT หรือฝ่ายใด ฝ่ายหนึ่งเพียงอย่างเดียวนะครับ
หลักสำคัญของ Agile คือ การรวมหัวกันคิด ร่วมมือกันทำ และ คำนึงถึงลูกค้าเป็นสำคัญ นะครับ
วันนี้ผมได้รับความเห็นเพิ่มเติมที่สำคัญมาและอยากเอามาเพิ่มเติมเต็มให้กับบทความครับ เป็นความคิดเห็นทรงคุณค่าจากพี่ โอฬาร อึงอำนวยพร
ผมขอมองอีกมุมนึงครับวอร์ม
ผมคิดว่า การทำ Scrum แบบ checklist แล้วไม่ work ไม่น่าแก้ด้วยการใส่ Discovery/Delivery track, UX, etc.ตรงๆ นะ ผมมองว่าเทคนิคเหล่านั้นเป็น “ปลายเหตุ” หรือ “ปลายทาง” ครับ
คือถ้าตามบริบทของ Scrum เพียวๆ. มันเป็นแค่ framework ไม่ใช่ process ถ้าทำแล้วมันเหมือนเดิม (หรือไม่ work) ก็แสดงว่าเราทำแล้วไม่ได้ improve คือน่าจะลืมเสา 3 เสาที่ค้ำ Scrum อยู่ มันเลยพังลงมา ผมหมายถึง 3 Pillars of Scrum ครับ …
Transparency เพื่อให้เห็นปัญหา
Inspection วิเคราะห์ว่าสาเหตุคืออะไร
Adaptation เรียนรู้ ปรับตัว แก้ไข
ผมเลยมองว่า dual-track, UX, หรือเทคนิคอื่นๆ เป็นส่วนที่มาแก้ปัญหาในเรื่องที่เราเจอ จากการ inspect & adapt ครับ (เป็นปลายทาง เป็น option อาจจะไม่ต้องท่านี้ก็ได้) มันนอกบริบทของ Scrum
ถ้าในบริบทของ Scrum ผมมองว่าเป็นเพราะขาด 3 Pillars นี้ไป การเอา Scrum มาใช้เลยเป็นแค่ พิธีสกรัม หรือ Scrum-checklist อย่างที่วอร์มว่ามา แล้วถ้าตกหลุมพรางเพิ่ม process ไปไกลกว่านั้น มันอาจจะกลายเป็นสัตว์ประหลาดที่พอเราจะเอา process ออก มันก็ทำไม่ได้แล้ว ถึงตอนนั้นก็ไม่ Agile อยู่ดี เพราะเรา aim ไปที่ ขาด process ไม่ใช่ 3 pillars
ส่วนที่เหลือในบทความ ผมเห็นด้วยหมดเลยครับ 🙏
Reference: https://www.scrumguides.org/scrum-guide.html
