ทีมของคุณแก้ไขปัญหา และ อุปสรรคต่าง ๆ อย่างไรบ้าง ?

วันนี้ได้อ่านบทความจาก Front Row Agile
เรื่อง Agile Teams: When is an Impediment Just a Complaint?
ว่าด้วยแนวทางแก้ไขปัญหา หรือ อุปสรรคต่าง ๆ ที่เกิดขึ้นมา
โดยคำต่าง ๆ ที่ใช้จะอยู่ในบริบทของ Scrum
แต่สามารถนำมาประยุกต์ใช้ในการทำงานได้อย่างดีนะ
มาเริ่มกันเลย…

ว่าด้วยเรื่องของ Impediment หรือ ปัญหาอุปสรรคต่าง ๆ

ใน Scrum เขียนไว้ว่า “Scrum Masters should remove impediments”

นั่นหมายความว่า
ในทุก ๆ วันทีมจะทำสิ่งที่เรียกว่า Daily Scrum
เพื่อพูดคุย บอกเล่าและอธิบายให้กับสิ่งที่ทำไปเพื่อให้เป้าหมายที่ตั้งไว้สำเร็จ
สิ่งที่สำคัญมาก ๆ คือ ปัญหา และ อุปสรรคที่เกิดขึ้น
ทุก ๆ คนในทีมจะต้องพูดออกมา และ ต้องทำให้เห็นชัดเจน (Visible)
เพื่อให้ทุก ๆ คน หรือ คนที่เกี่ยวข้องเห็น และ แก้ไขต่อไป

ปัญหาหลัก ๆ คือ
เราไม่เห็นปัญหา และ อุปสรรค จนกว่าเรื่องมันจะแดงออกมา
และกลายเป็นปัญหาที่ใหญ่มาก ๆ

ปกติปัญหาต่าง ๆ จะอยู่ใน soft file หรืออยู่ในระบบใดระบบหนึ่ง
ซึ่งน้อยคนมากที่จะเข้าไปดู
ดังนั้นแนะนำให้ใช้ Physical board
สำหรับเขียนปัญหา และ อุปสรรค ซะ
และวางอยู่ในจุดที่ทุก ๆ คนที่เกี่ยวข้องเห็นได้ง่าย

ไม่เช่นนั้น ปัญหา และ อุปสรรค มันจะเป็นแค่การพูด ความไม่พอดี
ผมมักจะเรียกว่า มันคือ “ตด”
มันจะเหม็นสักครู่ ไม่กี่นาทีต่อมาก็หายไป
ที่สำคัญมันจะยังคงอยู่ตลอดไป … !!!

บ่อยครั้งที่ปัญหาเหล่านั้น มันกลับกลายเป็นข้อจำกัดซะอย่างนั้น !!!

ส่วนปัญหาที่มีความซับซ้อนล่ะ จัดการอย่างไรดี ?

ตัวอย่างเช่น

• ปัญหาเรื่องความเสถียรบน production server
• ปัญหาระบบ continuous integration ทำงานช้า
• ปัญหาเหล่านี้ต้องใช้เวลาในการแก้ไขปัญหาเยอะ และ ยากต่อการแก้ไข

ดังนั้นสิ่งที่ต้องทำ คือ Root cause analysis
เพื่อหาว่าจริง ๆ แล้วต้นเหตุของปัญหาที่แท้จริงคืออะไร
และมีแนวทางในการแก้ไขอะไรบ้าง

แต่ปัญหาส่วนใหญ่ที่พบเจอ คือ ปัญหาที่พบเจอมันใหญ่เกินไป
เนื่องจากเป็นปัญหาที่ซ่อนกันมานาน หรือ ปัญหามันอยู่มานานเกินไป
ทำไมนะ ?
อ้าวตอบกันมาหน่อยสิ !!

ทีม องค์กร ของคุณทำการจัดการกับปัญหา และ อุปสรรคกันอย่างไร ?

ในบทความได้ทำ brainstorm จาก Scrum Master ขององค์กรใหญ่ ๆ
ซึ่งได้ปัญหา และ อุปสรรคที่มักพบเจอจำนวนหนึ่ง ดังนี้

• Stakeholder นั้นต่อต้าน Agile และ Scrum
• Agile และ Scrum ไม่ได้รับการสนับสนุนจากฝ่าย management
• ทีมไม่มีอำนาจในการสั่งการเมื่อต้องทำงานร่วมกับส่วนอื่น ๆ หรือกับทีมที่เกี่ยวข้อง
• Product Owner พยายามที่จะควบคุมทีมมากจนเกินไป เหมือน manager
• ทีมรู้สึกว่า มี Scrum Master ก็ไม่ได้ช่วยอะไร

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

ลองคิดดูกันหน่อยว่า
ถ้าเขียนปัญหาเหล่านี้ขึ้นที่ Physical board ซึ่งทุก ๆ คนเห็น
แล้วมันจะเกิดอะไรขึ้นตามมา ?
มันคือปัญหา เรื่องความสัมพันธ์ระหว่างทีม กับคนที่เกี่ยวข้องใช่ไหม ?
ซึ่งมันไม่น่าจะเกิดขึ้นใช่ไหม ?
มันคือปัญหาเรื่องคน น่ากลัวมากนะ !!

ดังนั้นให้ทีมกลับมาคิดหน่อยสิว่า ปัญหา และ อุปสรรคเหล่านั้นมันเป็นจริง ๆ หรือไม่ ?
ให้ลองพิจารณาดังนี้

• ทำความเข้าใจสิว่า มันคือ ปัญหาจริง ๆ สำหรับทีมหรือไม่
• หรือแค่เป็นเพียงข้ออ้าง หรือ สิ่งที่ไม่พอใจ
• มันคือการกล่าวโทษคนอื่นหรือไม่

ให้สรุปข้อมูล และ ตัวอย่างที่เกิดจากปัญหา รวมทั้งผลกระทบที่เกิดขึ้น

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

ตัวอย่างเช่น ทีมรู้สึกว่า ไม่ได้รับการสนับสนุนจากฝ่าย management

ส่วนใหญ่ปัญหานี้ เกิดมาจาก
ทีมรู้สึกว่า Scrum Master ไม่ได้ช่วยอะไรทีมเลย
ทีมรู้สึกว่า Scrum Master ไม่ได้มาทำแบบ full-time job
ทีมรู้สึกว่า Scrum Master ไม่ได้เข้าไปทำงานร่วมกับฝ่าย management อย่างเพียงพอ

จากปัญหาเหล่านี้ จริง ๆ แล้ว คือ
Scrum Master มันคือ role ใหม่ในองค์กร
และคนเหล่านั้นยังไม่เข้าใจในสิ่งที่ตนเองต้องทำ
รวมทั้งเรื่องการทำงานแบบ full-time job

ผลกระทบที่เกิดขึ้น
เช่นต้องเลื่อน Retrospective ไปยัง sprint ถัดไป
เพราะว่า Scrum Master ยุ่งมาก มีงานอื่นทำอีกมากมาย !!

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

จากปัญหา และ อุปสรรค ตัวอย่างนี้ มีวิธีการแก้ไข หรือ ทุเลา อย่างไรบ้างนะ ?

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

ทีมควรกำหนด Working agreement หรือ กำหนดการทำงานของทีมซะ
ถ้า Scrum Master ยุ่ง หรือ ติดงานจริง ๆ
ก็ให้คนในทีมมาทำ Retrospective เองเลยสิ

แต่ก่อนหน้านั้น Scrum Master ต้องสอน และ แบ่งปันก่อนนะว่า
Retrospective มันคืออะไร ?
Retrospective ทำเพื่ออะไร ?
ทำ และ ไม่ทำนั้นจะเกิดอะไรขึ้นบ้าง ?
พาทำ และ ให้ลองทำ เพื่อให้ feedback กลับไป

ทำการเปิดสอน Agile/Scrum สำหรับ manager และ development
เพื่อทำการอธิบาย และ ให้เห็นว่า
Role ของ Scrum Master เป็นอย่างไรบ้าง
Role ของ Scrum Master มีความสำคัญอย่างไร

แนะนำให้ลอง Scrum Master มาทำงานแบบ full-time job
สักประมาณ 2-3 เดือน เมื่อเสร็จสิ้นให้ทำการประเมินผลซะ

แนะนำให้ลองค้นหาด้วยตัวเอง ว่า
ทีม องค์กรอื่น ๆ เขาแก้ไขปัญหาอย่างไรบ้าง ?
แต่ขอให้ระวังในการนำมาใช้งาน
เนื่องจากแต่ละที่ มีบริบทของปัญหาแตกต่างกัน

ปิดท้ายด้วยคำถาม

• ปัญหา และ อุปสรรค นั้นทุกคนในทีมเห็นหรือไม่ ?
• คุณแก้ไขปัญหา และ อุปสรรคอย่างไร ?
• วิธีการแก้ไขปัญหาออกมาจากทีม หรือ ข้อตกลงร่วมกันของทีมหรือไม่ ?
• คุณเห็นปัญหา และ อุปสรรค ช้าหรือเร็วเพียงใด ?
• ปัญหาเหล่านั้นถูกแก้ไข หรือ เกิดขึ้นมานานหรือไม่ ?

Reference Websites
http://www.infoq.com/news/2013/05/scrum-master-impediments
http://scrummethodology.com/scrum-impediments/
https://www.scrumalliance.org/community/articles/2011/september/five-tips-for-impediment-resolution-with-scrum