เลข Sprint ที่หายไป

เช้าวันหนึ่งอากาศสดใส และเป็นวันเริ่มต้นของ sprint ใหม่ของทีมที่ผมกำลังโค้ชอยู่ วันนี้ผมมาเป็นคนแรก แล้วพบว่าใบเซ็นชื่อหมด ผมก็เลย print ใบเซ็นชื่อใหม่ ผมเห็นว่าใบเซ็นชื่อ sprint ที่แล้วเขียนไว้ว่าเป็น sprint ที่ 244 แต่พอมาดูใน sprint backlog ของทีม เห็นว่าบน product backlog item เขียนว่า sprint ที่แล้วเป็น sprint 241 ผมก็เลยงงว่า sprint นี้ควรจะเป็น sprint ที่ 245 หรือ 242 กันแน่

ผมลองไล่ใบเซ็นชื่อที่ผมเคย print ใบก่อน ๆ ดู พบว่า จากที่ผมจดไว้ sprint นี้ควรเป็น sprint ที่ 241 ต่างหาก อ้าว!? ตกลงมันควรจะเป็น 241, 242 หรือ 245 กันแน่เนี่ย???

หนังสือ Coaching Agile Teams สอนผมว่า

เมื่อไหร่ที่ ScrumMaster เผชิญกับปัญหาที่แก้ไม่ตก ให้ไปพึ่งปัญญาของทีม

ผมก็เลยไปถามทีมว่า “ทีม! Sprint นี้เป็น sprint เท่าไหร่กันแน่นะ?” แล้วทีมก็เงียบ… ผมนี่เหงื่อตกเลย นี่ผมกำลังเผชิญปัญหาที่มันเกินปัญญาของทีมจริง ๆ เหรอเนี่ย?

ผมไปไล่สัมภาษณ์สมาชิกของทีม เพื่อรวบรวมข้อมูลว่าเกิดอะไรขึ้นกันแน่ ได้ข้อสรุปตามภาพด้านล่าง

ทำไมเลข sprint ถึงหายไป?

เพราะค.รู้สึกว่าเราทำงานเป็น sprint หายไป

ทำไมค.รู้สึกว่าเราทำงานเป็น sprint หายไป? เพราะ

1. หลัง ๆ เวลาเราทำงานไม่เสร็จ เราก็ยกไปทำ sprint หน้า
2. เรา commit ของทีละ 2–3 sprint (เหมา ๆ ทำไป)
3. เราไม่ plot sprint burndown

ทำไมเราไม่ plot sprint burndown? เพราะมีของแทรกกลาง sprint บ่อย

Sprint หายไปแล้วมีผลกระทบอย่างไร?

1. ตามความเข้าใจผม เหตุผลหนึ่งที่ Scrum ให้ทำงานเป็น sprint เพราะ ถ้าทีมเข้าใจ requirement ไม่ตรงกับ Product Owner แล้วเค้าไม่รู้ตัวก่อน sprint review เลวร้ายสุดที่จะเกิดขึ้นได้คือ ไปร้อง อ้าว! กันตอน sprint review ถ้าเราไม่มี sprint เวลาผิด ก็จะผิดได้เยอะขึ้น
2. ผมมอง sprint เป็น gamification เล็ก ๆ ใน Scrum เพราะ sprint ทำให้เกิด sprint success และ sprint fail ซึ่งพอ gamification เล็ก ๆ นี้หายไป ผมมักจะเห็นทีมเนือย พอเนือยนาน ๆ ก็จะเริ่มเบื่อ

ข้อสรุปข้างบนเป็นแบบย่อนะครับ ข้อสรุปที่ละเอียดกว่านี้อยู่นอก scope ของ blog นี้ครับ

หลังจากเก็บข้อมูลได้แบบนี้แล้ว ผมก็กำลังเช็คกับตัวเองว่า การค้นพบนี้เชื่อถือได้แค่ไหน? นี่ผมกำลังค้นพบโอกาสการเติบโตสำหรับทีมที่ยิ่งใหญ่ หรือผมกำลังเกาทั้ง ๆ ที่มันไม่คันกันแน่? โชคดีที่ ชาว Odd-e มีแนวปฏิบัติที่เรียกว่า Odd-e never does ข้อหนึ่ง กล่าวว่า

Never limits our thinking to one perspective.

ผมจึงเอาข้อสรุปนี้ไปเช็คกับทีมอีกหลาย ๆ คน ตั้งแต่คนที่มักจะเห็นด้วยกับผม ไปจนถึงคนที่มักจะเห็นต่างกับผม แล้ว feedback ที่ผมตีความได้ก็มีตั้งแต่ “นี่มันเป็นปัญหาที่ยิ่งใหญ่มาก เราต้องรีบ retrospec เรื่องนี้แล้วหล่ะ” จนถึง “แค่เลข sprint หายนี่คุณมโนไปได้ไกลปานนี้เชียว” :D

แต่สิ่งหนึ่งที่เป็นเอกฉันท์คือ เราควรรายงานข้อมูลนี้ให้ผู้บริหารทราบ แล้วเราก็ควรจะทดลองทำอะไรกับสิ่งนี้ดู

ผมเรียนรู้อะไรจากเหตุการณ์นี้

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

ประสบการณ์นี้เป็นการย้ำเตือนตัวเองได้ดี ว่าผมต้องแยกให้ออก ว่าผมเห็นอะไร และเรา (SM+PO+Team) เห็นอะไร ก่อนหน้านี้เป็นครึ่งปีผมเคยถาม ว่า sprint burndown มันหายไปแล้วหนิ นี่เป็นปัญหาไหมนะ? หรือผมแชร์ว่าเดี๋ยวนี้มี item แทรกกลาง sprint บ่อยขึ้นหนิ มีปัญหาไหมนะ? แล้วผมไม่ได้ยินว่ามีปัญหา ซึ่งแม้สิ่งเหล่านั้นจะเป็นปัญหาของบทบาทผู้คุมกฏในฐานะ SM ของผม แต่มันยังไม่ใช่ปัญหาของเรา ปัญหาของผม ผมก็ต้องแก้ ถ้าอยากให้เราแก้ ก็ต้องรอปัญหาของเรา

ผมเชื่อว่า sprint เป็นธรรมชาติ การที่ sprint หายไปมันผิดธรรมชาติ สิ่งที่ผิดธรรมชาติจะไม่ยั่งยืน รอไปเรื่อย ๆ เด๋ว sprint ก็กลับมา :)

ผมกำลังเอาจุดเปราะบางของเรา (ผม+ทีมผม) มาแชร์ ด้วยค.หวังว่ามันอาจจะเป็นประโยชน์กับผู้อ่าน ผมจะดีใจมาก ถ้าได้ยินว่ามันมีประโยชน์กับผู้อ่านอย่างไร

ผมยินดีรับค.คิดเห็น และเตรียมใจไว้แล้วที่บางท่านอาจจะสงสัย และอยากถามคำถามเพื่อเข้าใจบริบทมากกว่านี้ ผมอยากขอให้ทำด้วยค.ระมัดระวัง เพราะในพื้นที่เปราะบาง คำพูดเราอาจจะทิ่มแทงกันได้โดยไม่ได้เจตนา :)

ขอบคุณที่สละเวลาอ่านครับ หวังว่าจะมีประโยชน์ไม่มากก็น้อยครับ ^/\^