ทำไมผมถึงไม่อยากเป็น Scrum Master

Phattararak Dhuamreongrom
4 min readOct 5, 2023

ในช่วงระยะเวลาที่ผ่านมา มีบริษัทมากมาย ไม่ว่าจะเป็น recruiter หรือ ตัวบริษัทเอง ที่ติดต่อเข้ามา ด้วยความที่ว่าเรามีประสบการณ์เกี่ยวกับ Agile และก็ Certified ด้าน Scrum Master และ Product Owner มา ดังนั้นทุกคนที่ติดต่อก็มาก็คาดหวังว่าความรู้ความสามารถเราจะ fit in กับ Scrum Master ที่เขาตามหาได้

แต่ทุกครั้งที่เขาเสนอตำแหน่ง Scrum Master มาให้ ผมก็จะปฏิเสธไปทุกครั้ง … ทำไมถึงเป็นเช่นนั้น?

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

ผมเองทำงานใน position ที่ต้องปรับตัวที่เป็นทั้ง Project Manager และต้อง Acting เป็น Scrum Master ไปด้วย ตัวผมเองก็สามารถสวมหมวกนี้ได้ไม่มีปัญหาใดๆ เพียงแต่ว่าผมรู้สึกว่าเราแสดงมันออกมาเต็มที่ไม่ได้ เพราะมันมีกมลสันดานของ PM อยู่ และบางอย่างมันบอกเราว่า “เห้ย ณ สถานการณ์นี้เราทำตัวเป็น Scrum Master ไม่ได้อีกต่อไปแล้ว มัน critical มากๆแล้ว” ผมขอยกตัวอย่างเหตุการณ์ เช่น

  • ทีมมีการทำงานอย่างถูกต้องใน scrum framework แต่ทำไมไม่เคย deliver งานได้ตาม commitment เลยสักครั้ง เช่น deliver ได้ 50% ของ sprint goal
  • คุณเฝ้าแต่ทำ retrospective แถมมี action items ที่ชัดเจน แต่ก็ยังเกิดเหตุการณ์เดิมซ้ำๆ
  • คุณรู้อยู่เต็มอกว่า story point มันเกินกว่า historical data มากๆ แต่ก็ยังปล่อยให้เริ่ม sprint เพราะเชื่อมั่นว่าทีมจะทำได้แน่ๆใน sprint นี้
  • คุณรู้อยู่แล้วว่างานมันมีความเสี่ยง แต่คุณไม่คิดที่จะเข้ามา inspect ปล่อยจอย แล้วให้ทีมเผชิญชะตากรรม จนท้าย sprint กลับมาถามทุกคนว่า “เราคิดว่าจะ improve ยังไง”

สถานการณ์เหล่านี้ถ้าคุณยัง approach ด้วยวิธีเดิมๆ ซึ่งพิสูจน์มาหลาย sprint แล้วว่าแม่งไม่ work แล้ว จนกลายเป็นเรื่องปกติของทีมไปแล้ว … คุณจะมาสวมหมวกเดิม มันไม่ได้แล้วนะ มันเป็นเรื่อง critical เกินกว่าที่จะมา coaching, mentor แบบ scrum master มันไม่ทันการณ์แล้ว

จากสถานการณ์ตัวอย่าง ถ้าผมเปลี่ยนหมวกไปเป็น PM ผมเองสามารถหยุดความเลวร้ายนั้นได้ทันทีทันใด ซึ่งนี่แหละเป็นสาเหตุที่ผมรู้ตัวเองว่า ผมไม่อยากเดินไปในทางของ scrum master ล้วนๆ เพราะผมต้องการหยุดวงจรการทำงานอุบาทว์และเละเทะ รวมถึงมันมีเหตุผลบางประการที่มันไม่ใช่ตัวผมเลย

1. Sense of Urgency ที่มักจะหายไป

คือถ้าเลือดเนื้อคุณเป็น PM นะ … คุณจะทนไม่ได้ตั้งแต่แรกแล้ว คุณจะรีบเข้าไปเคลียร์ปัญหาลึกๆ เอาง่ายๆคือคุณจะเอาตัวเองเสือกเข้าไปเพื่อจะแก้ไขให้มันดีขึ้นและกู้สถานการณ์โดยเร็ว หรือถ้าเราดูแล้วมีความเสี่ยง เราจะไม่ปล่อยให้มันเกิดขึ้นแล้วตามแก้หรอกนะ

ซึ่ง…. ใช่แล้วผมเป็นแบบนั้น

ใน scrum framework เอง ก็มีเรื่อง commitment เป็นแก่น ซึ่งตัวผมเองก็ต้องการให้ทีมเคารพตัวเอง เคารพคำพูดของตัวเอง ซึ่งโอเคนะถ้ามันจะติดปัญหาอะไรก็เอามาคุยกัน แต่มันต้องมีความกระหายที่อยากจะทำให้ได้ตาม commitment …. ไม่ใช่ว่าปล่อยไปก่อนละกัน เดี๋ยว sprint หน้าเอาใหม่ release ไม่ได้ก็เลื่อนไปก่อน ปล่อยงาน spillover แล้วของเก่าไม่ทันจบ ของใหม่งอกอีกละ

2. ความไม่เชื่อในคณิตศาสตร์

งงไหม ว่าเกี่ยวอะไรกับคณิตศาสตร์ … เพราะ Scrum Master จะเชื่อมั่นในทีม encourage ให้ทีมเป็นคนพูดออกมา ว่าได้ไม่ได้ ไหวไม่ไหว แม้จะ estimated story point แล้วทะลุหลอดไป 3 เท่าจากค่าเฉลี่ย velocity แล้วก็ตาม

ส่วนผมในหมวก Project Manager ไม่ใช่ว่าไม่เชื่อว่าทีมทำไม่ได้นะ … แต่ถ้า Historical data มันสวนทางกับการที่ทีมบอกว่า “น่าจะทำได้” … เอาอะไรมาทำได้ก่อน

คำพูดสัญญาลมๆแล้งๆ ที่ไม่สามาถแปลงกลับมาเป็น Measurement ที่จับต้องได้ มันสู้อะไรไม่ได้กับหลักฐานและข้อมูลที่ Project Manager ถืออยู่ … คือแกจะท้าทายอะไรก็ได้นะ แต่แกจะมาท้าทายคณิตศาสตร์ไม่ได้!

Project Manager ที่ Certified จะทราบดีว่า มีสูตรในการคำนวณกลับมากมายที่สามารถบ่งบอกสถานะการณ์ของงานหรือโปรเจคนี้ได้ แต่พวกเขามักไม่งัดมันออกมาใช้หรือให้ใครดู ถึงแม้ว่าเขาจะไม่ได้แสดงเป็นตัวเลขให้เห็น แต่ไม่ได้หมายความว่าเขาเหล่านั้นไม่มีตัวเลข เพราะเมื่อไหร่ก็ตามที่งัดตัวเลขขึ้นมา ก็มีแต่จะบั่นทอนจิตใจทีมและองค์กรกันเปล่าๆ ดังนั้นเขาเหล่านั้นมักใช้วิธีการสื่อสารที่เรียบง่ายแทนการเอาตัวเลขแห่งความเป็นจริงมาให้ดู

3. ไม่อยากให้กดดันเกินไป อยากให้ทีมมุ่งเน้นไปที่ self organized และ deliver value

จริงๆอันนี้ดี ถูกต้องและเห็นด้วยเลยว่า สิ่งที่เรา deliver ต้องสร้าง value และทีมต้อง self managed, self organized ได้ และมันก็ทำได้จริงๆ เพราะผมทำมาแล้ว คำพูดนี้ทำได้จริง 100%

แต่!! … เราต้องย้อนดู history ตัวเองหรือทีมอีกเหมือนกันนะว่า มันมีความเป็นไปได้แค่ไหน

  • จะ deliver value ใน product แต่ไม่มี product ออกมาตามที่สัญญาไว้… แล้วแกจะเอา value มาจากไหนก่อน?
  • บางทีก็บอกว่า นี่ไง เราได้เรียนรู้จากความผิดพลาด … พูดสวยหรูไปอีก … ใช่เราได้เรียนรู้ แล้วทำไมเรายังไม่วาร์ป ทำไมไปไหนไม่ได้ ทำไมเราไม่พัฒนาล่ะ แน่นอนว่าหากเราเรียนรู้แล้วแก้ไขได้ช้า ก็จะทำให้เกิด overhead ในแง่ของ Time to market และ Cost ที่องค์กรต้องแบก
  • ถ้าเราพร่ำบอกว่า ให้ทีม self-managed/organized มันดี … ไหนล่ะ commitment ที่เราบอกว่าจะทำได้ตาม Sprint Goal … คือมันจะต้องสอดคล้องกันถูกไหม

การที่ Project Manager เสนอหน้าหรือเสือกเข้ามาใน scrum team บอกเลยว่าไม่มี PM คนไหนอยากทำ เพราะตัวเขาไม่ได้เป็นส่วนหนึ่งของ scrum framework แต่หลายๆครั้งที่เข้ามา เพราะเหมือนจะไม่รู้ตัวกันนะว่าอาการมันโคม่าแล้ว มีแนวโน้มจะ sprint fail สูง ดังนั้น PM ส่วนใหญ่เลือกที่จะเข้ามาเสือก เพื่อหาวิธีการที่ชัดเจนและเด็ดขาดมากพอที่จะจบปัญหาเหล่านั้น

4. Scrum Master ผูกติดกับ Scrum Framework

ส่วนตัวผมยังมองว่า Project Manager นั้น มันไม่ได้ยึดกับอะไรเลย คือ ถ้า Way of work นี้ไม่ดี เราเปลี่ยนไปใช้วิธีอื่น หรือ fix cost, fix scope เรายังจะทำ scrum ไปทำไม เราไป approach วิธีอื่นที่ดีกว่าได้

ส่วน Scrum Master เป็น Position ที่เกิดขึ้นมาใน Environment ที่ใช้ Scrum เป็นหลัก ในกรณีที่วันใดวันหนึ่ง Scrum Framework อาจจะไม่ได้เหมาะสมกับองค์กรอีกต่อไป หน้าที่รับผิดชอบของ Scrum Master ก็จะเปลี่ยนไปเป็นอย่างอื่นแทน

5. การแสดงเล่นใหญ่รัชดาลัย

Scrum Master ในประเทศไทย นี่เงินเดือนหลักแสน กันทั้งนั้นนะ ด้วยหน้าที่ของการผลักดันกระบวนการ scrum ให้องค์กรนำ scrum framework ใช้ได้อย่างเหมาะสมและถูกต้อง

แต่ถ้าให้สาบาน และพูดกันอย่างตรงไปตรงมา การผลักดันเหล่านี้ ต้องใช้สกิลในการแสดงสูงมาก ให้คนในองค์กร believe ใน scrum แต่ถ้าผลลัพธ์ที่ออกมานั้นกลับสวนทางกันอย่างสิ้นเชิง ทีมไม่ได้สร้าง Valuable Incremental แถม developers ทำงานทั้ง functional และ non-functional เยี่ยงทาส เขียนโค้ดเอย ประชุมเอย วางแผนเอย ประสานงานเอง แต่ scrum master กลับถูกเขียนให้เป็น coaching หรือ mentor ให้กับ Scrum Team เป็น servant leader และ facilitator

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

ผมอยากมีส่วนช่วยแบ่งเบาภาระ และทำงานไปด้วยกันกับทีมตลอดเวลามากกว่า เราอยากโตไปพร้อมๆกัน เราอยากมีส่วนร่วมคิดวิเคราะห์ปัญหาร่วมกับ Developers ทั้ง Technical และ Non-Technical รวมถึงปรับปรุงวิธีการทำงานให้ทุกคนทำงานง่าย ลดภาระ และรวดเร็วมากขึ้น

ทางเดียวที่ทำให้ผมไม่รู้สึกละอายใจ คือผมต้องฉีกหมวก scrum master ทิ้งไปซะ ผมจะทำทุกอย่างที่จะช่วยทีมทำงานได้ไวขึ้น ทำตามที่ commit ไว้ให้จงได้

มันมีแบบทดสอบนึงที่น่าสนใจ จากหนังสือ Agile Project Management ของคุณ Anthony Mersino โดยดูจากคำถามเหล่านี้ว่าคุณตอบ Yes/No กี่ข้อ (** ผมใส่คำตอบของผมเองไว้ท้ายข้อ)

  1. Do you feel that you need to monitor your team members so that they don’t slack off? — Yes
  2. Do you believe that you generally know what is best, and willingly offer solutions and advice? — Yes
  3. Do you tend to interject yourself into problem solving, even when you are not invited to get involved? — Yes
  4. Do you try to make the results conform to your idea of what the results should be? — No
  5. Do you feel uncomfortable when others are in control and you are not? — No
  6. Do you feel uneasy by the idea that your employees or team may operate fine without you? — No
  7. Do you feel the need to be involved in the details and decisions to reduce the risk of the project failing or having a misstep? — Yes
  8. Do you feel solely and personally responsible for the success and failure of the people you lead? — Yes
  9. Do you tend to step in or override others to protect them from possible mistakes or the consequences of their decisions? — No

ถ้าคุณตอบ Yes มากกว่าคุณก็จะมุ่งเน้นไปการ Monitor and Control ซึ่งเป็นคุณสมบัติของ PM มากกว่า ในทางตรงกันข้ามถ้าตอบ No มากกว่าก็จะเอนเอียงไปทาง Scrum Master มากกว่า

และอย่างที่เห็น ผมตอบ Yes 5 ข้อ และ No 5 ข้อ จริงๆด้วย ผมจึงไม่แปลกใจเลยว่าทำไม่ผมถึงไม่ได้อยากเป็น Scrum Master

สุดท้ายนี้ผมก็ไม่รู้เหมือนกันว่าจะนิยามตัวเองว่าอะไรดี PM ก็ไม่ใช่ SM ก็ไม่เชิง เป็นทั้ง PM/SM และก็ไม่เป็นทั้ง PM/SM ในเวลาเดียวกัน หรือจริงๆแล้วก็อาจจะโอนเอียงไปทาง PM มากกว่า…

เวลาน้องมาถามว่า PM / SM หน้าที่ทั้งสองมันต่างกันอย่างไร คือเราก็ตอบได้แหละว่ามันต่างกัน แล้วก็อธิบายเชิงทฤษฎีและเชิงปฏิบัติ ตามที่หาอ่านได้ใน Google

แต่ถ้าถามว่า ตกลง “ผมทำหน้าที่อะไรกันแน่” …. ณ ตอนนี้ก็ต้องตอบว่า “เป็นทุกอย่าง” และ “ไม่ได้เป็นซักอย่าง”

มันเหมือนกับว่าเราเป็นจอมยุทธ์กระบี่ เรามีกระบี่ เราใช้เพลงกระบี่ และเราฝึกฝนจนเป็นเซียนกระบี่ แต่สุดท้ายแล้วตอนที่เราออกท่องยุทธภพ เราต้องเป็นขั้นที่เหนือกว่านั้น คือ “ไร้ซึ่งกระบี่”

--

--

Phattararak Dhuamreongrom

Project Manager (PMP #2793547), Scrum Master (PSM I #740163), Product Owner (PSPO I #955684)