Agile,Scrum

Certified ScrumMaster Day 1/3 : Part 3/3

หลังจากเขียน มาได้ 2 อันเริ่มรู้สึกว่าเนื้อหา และสิ่งที่ได้จากการไป CSM เนี่ยมันเล่าได้เป็นบท ๆ เลย เพราะในตอนที่เทรนนั้น มีสิ่งที่หาไม่ได้จากการหาอ่านตาม Blog หรือการอ่านหนังสือเยอะมาก ทุกคำถามที่อยู่ในใจมันได้รับการตอบรับ จากคนที่รู้จริง แถมได้รับแบบตรงจุด มันสุดยอดกว่าการต้องไปไล่หาคำตอบเองเยอะมาก ๆ แต่สุดท้ายสิ่งที่ได้รับจาก Class คือ Mindset และที่สำคัญไม่แพ้กันคือ ได้รับรู้ว่าถ้าจะเข้าใจอย่างแท้จริงต้องทำ ๆ ๆ

หลังจากที่ใน 2 Blog ที่ผ่านมาเราได้สัมผัสกับ Bas แบบตัวเป็น ๆ ไปแล้ว ก็ถึงคราวพระเอกรองเท้าแดงของเรามาวาดลวดลายด้วยภาษาอังกฤษ แบบพูดไฟแล๊บกันเลย โดยเริ่มจาก Scrum Overviews ตามด้วยกิจกรรมสำคัญเพื่อให้เข้าใจ Role and Responsibility อย่าง Where is PM ?

Scrum Overviews

กิจกรรมเริ่มต้นจากให้คุณลองนึกภาพของ Scrum แล้วให้เขียนมันออกมาบน A4 เปล่า ๆ สักใบ เขียนอะไรก็ได้ที่อธิบายความเป็น Scrum ออกมา แน่นอนเขียนเสร็จแล้ว เอาซ่อนไว้ก่อน (จริง ๆ ทุกคนได้รับการบ้านให้ไปอ่าน ScrumPrimer : http://scrumprimer.org/ ก่อนที่จะเข้าชั้นเรียนเพื่อเป็นการศึกษาความรู้ก่อน) … จากนั้นพี่รูฟก็วาดลวดลาย ซึ่งเป็นครั้งแรกที่ผมเห็นพี่รูฟซัดภาษาอังกฤษยาว ๆ (แถมดูเป็นงานเป็นการมาก) ทั้งวาดภาพ Overviews ของ Scrum ตามไปด้วย

FB_IMG_13759506335667745สิ่งสำคัญที่ได้จากรูปที่แกวาดออกมาคือ Scrum มีสิ่งสำคัญอยู่ข้างใน 3 อย่างคือ Roll, Activity, Artifact

Scum Role

  • Product Owner (PO) รู้ว่าต้องสร้างอะไร
  • Team รู้ว่าจะสร้างสิ่งนั้นอย่างไร
  • SM ทำให้แน่ใจว่า PO และ Team ได้ Benefits จาก Scrum ให้มากที่สุด

ก่อนจะไปจุดต่อไป ในภาพที่ทำการกำหนดขนาดของ Sprint จะอยู่ที่ประมาณ 2-4 Weeks ซึ้ง Bas ก็เดินมาเสริมว่าจริง ๆ แล้ว เขาไม่ Recommend ให้ทำ Sprint ละ 4 Weeks เอามาก ๆ เลยนะ คำถามเดิม ๆ ที่เคยถามไปแล้วจึงถูกขุดขึ้นมาถามใหม่ “ทำไมทำ Sprint ละ 4 Weeks ถึงไม่ดีเอามาก ๆ” จึงเข้าทาง Bas เพราะ Bas ถามกลับทันทีว่า ทำไมเราถึงต้องมี Timebox และทำไมต้องทำ Sprint ด้วยเวลาสั้น ๆ คำตอบคือ “Feedback Loop” เพื่อเอามาใช้ในการ Inspect & Adapt

Bas จึงเริ่มยกตัวอย่างการเล่นนดนตรี ลองจินตนาการว่าคุณกำลังจะหักเล่น กีตาร์ (มุกนี้คุ้น ๆ กับใน Hyper Productivity เลยไม่เหนื่อยกับการแปลระหว่างฟังมากนัก) ลองหยิบกีตาร์มาวางบนตัก จับคอร์ด ลงมือดีด แล้วเสียงจะมาภาพในอีกประมาณ 2 Weeks คำถามคือ ถ้าเป็นคุณคุณจะใช้เวลากี่วัน/สัปดาห์/ปี ในการเรียนเพื่อให้สามารถเล่น กีตาร์ ได้ … คำตอบคือ ไม่เลย เพราะหลังจากคุณได้ยินเสียง (แน่นอนว่าคุณอาจจะลืมว่าได้ดีดมันไป) แม้ว่าคุณจะตั้งหน้าตั้งตารอเสียงนี้อยู่ หลังจากคุณได้ยินเสียงซึ่งครั้งแรกมันของเราเสียงมันคงไม่ดีนัก คุณก็อาจจะอยากจะปรับเปลี่ยนวิธีการดีดไปเป็นอย่างอื่น เพื่อให้เสียงมันดีขึ้น … เอ๊ะ … แล้วครั้งที่แล้วเราดีดยังไงไปหว่า ไม่เป็นไรดีดไปแล้วกัน …แล้วนั่งรอไปอีก 2 สัปดาห์ (เป็นผมคงเลิกเล่นไปตั้งแต่ 2 วันแรกแล้วมั้ง) ปัญหาคือหลังจากรอไปอีก 2 สัปดาห์คุณก็จะจำอะไรไม่ได้แล้วไม่รู้จะเปรียบเทียบอะไรกับเมื่อ 2 สัปดาห์ก่อนได้เลย ว่าเสียงที่ได้ยินมันดีขึ้นหรือเลวลง (หรือจะลงทุนอัดเสียงมาเปรียบเทียบหล่ะ … นึกในใจไม่ได้ถามไปนะ 555+) นี่แหละที่เป็นจุดที่ Waterfall ไม่เคยสามารถบอกอะไรเพื่อให้เราสามารถปรับเปลี่ยนการทำงานของเราให้ดีขึ้นได้เลย ,,, คุณไม่สามารถ Inspect & Adapt ในการเรียนกีตาร์ (หรือทำงาน) ของคุณได้เลย

มาถึงจัดนี้ Bas พูดเกี่ยวกับอะไรอีกสักอย่างเกี่ยวกับการเก็บ Feedback โดยยกตัวอย่างจากการร้องเพลง, Bas บอกว่าได้เจอคนคนนึงที่ร้องเพลงได้เสียงเพราะมาก (ไปคาราโอเกะ หรืออะไรเนี่ยแหละ) (เหมือนจะบอกว่าเป็นภรรยาใครสักคน … ผมเดาว่าเมียพี่รูฟนะ 555+ มั่ว) คนนั้นบอกว่า “การที่คุณจะร้องเพลงได้เพราะ คุณต้องมีหูที่ดีเอามากและขยันร้องเพลงบ่อย ๆ” (เกี่ยวไรกันกับหูดี … งง)  Bas บอกว่าคนที่หูดีจะรับรู้ได้ง่ายว่าเสียงที่ตัวเองร้องไปดีหรือไม่ดี แล้วพยายามปรับปรุงวิธีการร้องของตัวเองให้เสียงดีขึ้น ๆ ๆ เพราะฉะนั้น ผมเลยสรุปเอาเองว่า Inspect & Adapt ใน Continuous Improvement ต่างกับ การลองผิดลองถูกไปเรื่อย ๆ เพราะเราต้องให้ความสำคัญของการเอา Feedback มาปรับปรุงสิ่งที่ทำอยู่ เพราะฉะนั้น การหา Feedback ที่ดีบอกทิศทางตรงตามที่ควรจะไป จึงเป็นสิ่งที่สำคัญมาก ๆ

คำถามสุดท้ายคือ ถ้าเราต้องเรียนกีตาร์เราจะเล่นเพลงเดิม ๆ ซ้ำ ๆ ไป หรือเราจะเล่นจบ 1 รอบแล้วเปลี่ยนเพลงใหม่ไปเรื่อย ๆ เลย …

Make Commitment

กลับมาที่ Scrum, ใน Scrum เราพูดถึงการทำ Sprint Planning ซึ่งแยกเป็น 2 ส่วน คือ Sprint Planning Part I (Confirm) และ Sprint Planning Part II (Design) ประเด็นคือหลังจากเราทำ Sprint Planning เสร็จ เราจะรู้ว่าอะไรบ้างที่เป็น Goal ของ Sprint นี้ (We are going for it.)  ซึ่งถือเป็น Commitment ร่วมกับ PO

จุดสำคัญที่ส่วนมากเราจะเข้าใจเกี่ยวกับ Scrum ผิดคือ Commitment ที่เราทำร่วมกับ PO หลังการทำ Sprint Planning !?!?! … เข้าใจผิดยังไงหน่ะเหรอ ? เรามักจะเข้าใจว่า Commitment แล้วต้องทำให้ได้ ไม่ว่าจะเกิดอะไรขึ้น (สิ่งแรกที่คิดคือ … อ้าวผิดตรงไหนว่ะ) เพราะเราสัญญาแล้วว่ามันจะเสร็จ แต่ Bas บอกประมาณว่า Commitment <> Promise นะ ประเด็นของมันคือ จริงอยู่มันไม่ดีแน่ถ้าคุณไม่สามารถทำได้ตามที่คุณ Commit กับ PO เพราะฉะนั้น เราต้องทำสิ่งที่ต้องเพื่อให้ได้ตามนั้น แต่ถ้ามันมีอะไรบางอย่างที่ทำให้มันไม่ได้ มันก็คือไม่ได้ สิ่งสำคัญของมันคือ การเรียนรู้จากมันต่างหาก

ลองเปรียบเทียบกับเกมส์กีฬาดูบ้าง … ถ้าสมมติว่าคุณเป็นทีมที่กำลังจะลงสนามหลังจากผลักกันแพ้ ผลักกันชนะมาในช่วงหลัง (ผมคิดว่า … แพ้มาตลอด หรือชนะมาตลอดก็เหมือนกัน) คุณกำลังอยู่ในห้องพักนักกีฬาก่อนลงสนาม ทุกคนในทีมมารวมตัวกันเพื่อประสานมือร้องให้กำลังใจทีม ทุกคนในทีมเกิด Commitment ที่จะทำทุกอย่างเพื่อพาทีมชนะในนัดนี้ คำถามคือถ้ามันแพ้กลับมาหล่ะ …

“มันยัง OK ถ้าเราจะทำไม่ได้ แต่มันไม่ OK ถ้าเราไม่ได้เรียนรู้อะไรจากมันเลย”

เพราะฉะนัันสิ่งสำคัญคือ “Change the way, they work” 

Sprint Review

มาถึงจุดของการเก็บ Feedback ของ Sprint จุดสำคัญของการทำ Sprint Review คือการ Get Real Feedback เพื่อมา Inspect & Adapt ในมุมมองของ Product ที่ทีมสร้างขึ้น ซึ่งส่วนมากเราจะหลงทางกับคำว่า Real Feedback เช่น การที่ Sprint Review มีแต่ PO เข้ามา Join ซึ่งจริงอยู่ส่วนมาก PO จะเป็นตัวแทนของ User หรือ Customer ที่เข้ามาใช้งานระบบ แต่ตัวแทนก็คือตัวแทน สิ่งสำคัญเพื่อให้ได้ Real Feedback คือการได้จากตัวจริง ฉะนั้นมีความจำเป็นอย่างมากในการเชิญเขาเหล่านั้นเข้ามาในขั้นตอนของ Sprint Review เพื่อเก็บ Real Feedback

ตัวอย่างจากระบบ Document Management System (ขำมากครับกว่าความต้องการจะถึงมือ Dev แทบจะไม่เหลือเค้าเดิม)

FB_IMG_13759506451563833

เป็นหน้าที่ของ SM ที่จะให้ Developer ได้สื่อสารโดยตรงกับ User

จาก Overview ของ Scrum เราจะเห็นว่าว่า Scrum ให้ความสำคัญกับเรื่อง Inspect & Adapt มาก ๆ และอีกสิ่งนึงที่เราจะได้จาก Scrum คือ Transparency ทั้ง 3 อย่างนั้นแทบจะเป็นหัวใจสำคัญของ Scrum เลยก็ว่าได้

Where is Project Manager ?

เนื่องจากใน Scrum มี Role อยู่เพียง 3 Role คือ Team, Product Owner และ SM (ซึ่งจำเป็นน้อยสุด 555+) ซึ่งไม่มี Project Manager อยู่ในนั้น เพราะฉะนั้นจึงเป็นคำถามว่าแล้ว Project Manager อยู่ตรงไหนของ Scrum ถึงจุดนี้ Bas บอกว่าสิ่งที่สำคัญในการพิจารณาไม่ใช่เรื่อง Role แต่เป็น Responsibility ของ PM (หรือก็คือ Project Management) ลองนึกถึงภาพเราอยู่ในบริษัทแล้วยก Role ออกไป ปริมาณงานก็ยังอยู่เท่าเดิม Responsibility ก็ยังอยู่เท่าเดิม เพราะฉะนั้น Role จึงไม่สำคัญ ในการคิดว่า PM อยู่ที่ไหนจึงควรต้องคิดก่อนว่างานที่ PMรับผิดชอบคืออะไร … แน่นอนหลายคนคงบอกว่า งานของ PM ก็ต้อง Manage Project สิ แต่นั่นมันหยาบไป

จริง ๆ ผมได้เคยลองทำ กิจกรรม “Where is PM ?” มาแล้วจาก Class Spartan ของ Sprint3r (https://www.facebook.com/Sprint3rThailand) โดยเราจะทำการ List Responsible ของ PM ออกมาว่าปกติ PM ต้องทำอะไรบ้าง แล้วจริงหยิบน่าที่เหล่านั้นมาหาที่อยู่ใหม่ อันไหนน่าจะอยู่ได้ 2 ที่ก็ ฉีกมันออกเป็น 2 ใบแล้วเอาเข้า Product Backlog ซึ่งตอนนั้นก็ดู Smooth ดีอยู่ แต่พอได้มาเล่นรอบ 2 จากของจริง ทำให้ได้เห็นอะไรดี ๆ เยอะมาก (ผมเข้าใจว่า Bas ให้ความสำคัญกับ Mindset มาก ๆ ถึงขนาดเดินวนดูทุกโต๊ะ เพื่อบอกว่าอะไรผิด อะไรต้องย้าย แต่หลังจากย้ายก็ยังผิดซ้ำ ๆ กันอีกอยู่ดี แปลว่าสิ่งที่เราเข้าใจในเรื่องของ Role มีความละเอียดมาก)

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

เพราะฉะนั้นในการ Implement หรือการพยายามนำ Agile หรือ Scrum เข้ามาในองค์กร มักจะพลาดเรื่อง Role กันเป็นเรื่องแรก ๆ เพราะทุกคนจะพยายาม Mapping หาที่อยู่ของตัวเอง แถมยังพยายาม Map กันแบบ 1 ต่อ 1 อีกด้วย เช่น …

  • Development Team และ Tester ที่เคยทำงานอยู่เดิมก็ออกจะง่าย หน่อย เพราะ มี Role ที่ชื่อว่า Team ของ Scrum รองรับอยู่แล้ว
  • งั้นคนต่อไป ก็ PO เน๊อะ แหม … อันนี้ไม่ค่อยยาก คนที่รู้ตรงนี้ก็น่าจะเป็นใครสักคนที่เป็นตัวแทนของลูกค้า ง่ายที่สุดก็หัวหน้าลูกค้าเพราะตัดสินใจอะไรต่อมิอะไรได้… (หรือถ้าลูกค้าไม่ได้ก็เอาคนในสักคนหล่ะว่ะมาเป็นแทน)
  • สุดท้าย งั้น PMก็ให้เป็น SM แล้วกัน … T^T

เหตุผลที่เเอา PM มาเป็น SM ผิดนั้น (อยากรู้อีกทีว่า SM ทำอะไรแล้วทำไม PM ถึงเป็น ลำบากไปดู http://www.agile66.com/blogs/2012/01/12/what-scrummaster-doe/) ในกิจกรรม Where is PM ? จะเห็นว่า บทบาทหน้าที่เดิมของ Project Manager จะถูกกระจายไปยัง PO และ Team เกือบทั้งหมด ตาม Focus ของแต่ละ Role แต่จะมีน้อยมาก หรืออาจะไม่มีเลยสำหรับบางกลุ่มที่ หน้าที่นั้นไปอยู่ทีื SM เพราะฉะนั้น การพยายามจะ Map Role ของ PM ไปยัง SM จึงเป็นการพยายาม Map สิ่งของที่แทบจะไม่มีความใกล้เคียงกันเลย …

งั้นคำถามต่อไปก็น่าจะเป็น “แล้วใครหล่ะที่สมควรจะมาเป็น SM …” คำตอบที่ผมพอจะกล้อมแกล้มฟังมาได้คือ จะเป็นใครก็ได้สามารถเป็น SM ได้หมด คำว่าใครก็ได้ (ดูสุ่มเสี่ยงมากในความคิดผม แบบว่าสงสัยว่าตัวเองกยังหวงอำนาจอยู่ … 555+) หมายถึง ใครก็ได้ที่มี Skill ที่เหมาะกับ SM มี Skill นะครับ ไม่ใช่มี Role (เหมือนผมจะแว่ว ๆ ว่า เนื่องจาก SM เป็น Role ที่เกิดขึ้นมาใหม่ ไม่มี Role เดิมไหนจะมาเปรียบเทียบได้เป๊ะ ๆ หรอก)

Bas ยังเสริมอีกว่าการที่จะดูว่าคน ๆ นั้น ทำงาน Role อะไรอยู่ ทำได้โดยการถามจากคนรอบข้างของคน ๆ นั้น ว่าคุณคิดว่าสิ่งที่เขาทำอยู่คืออะไร แล้วมันตรงกับ Role ไหน (เน้นที่การกระทำจริง ๆ ที่เขาแสดงออกมาอยู่ … อีกแล้ว) ไม่ใช่การดูว่า ตัวเขาเองประกาศว่าตัวเขาเองทำงาน Role อะไร

คำถามต่อไป (คำถามนี้อยากจะถามอยู่แล้ว ขอบคุณพี่ ๆ ที่ถามคำถามนี้ให้) คือ แล้ว Team Leader หล่ะ เป็น SM ได้หรือไม่ … รอคำตอบด้วยใจระทึกแล้วก็ได้รับคำตอบที่ทำให้เราปวดใจว่า “Team Leader เป็น SM ที่ดีไม่ได้ T^T” Bas บอกเสริมอีกว่า ถ้ามีคนจ้างเขาไป Consult แล้วเจอทีมที่ไม่แข็งแรงพอ เขาจะเอา Team Leader ออกไปไกล ๆ ก่อน (งั้นกูก็ไม่รอดสินะ T-T) เหตุผลหลัก ๆ ตรง ๆ คือ Team ที่ยังไม่แข็งแรงพอจะเคยชินกับการ Report คนเพียงคนเดียวมากกกว่าการ Report ให้ทั้งทีมฟัง เพราะฉะนั้น Team ก็จะหันไป Report ให้กับ Team Leader ฟัง (ทั้ง ๆ ที่ Team ที่ Self-Managed ควรจะ Sync และ Manage กันเอง Report กันเองมากกว่า) อันนี้โดนเข้ากลางใจผมเลยครับ ช่วงที่พยายามทำ Scrum แรก ๆ มันกลายเป็น Daily Report to Team Leader อย่างจริงจังเลย T^T

มาถึงจุดที่ผมสับสนอย่างสูงสุด (นี่กูทำผิดมาตลอดเลยใช่ไหมเนี่ย …) คำถามที่เกิดขึ้นคือ แล้วใครหล่ะที่เหมาะจะเป็น SM หรือ Role ไหนเหมาะจะมาเป็น SM ผมว่าจุดสำคัญคือ

  • มันไม่ขึ้นกับ Role มันอยู่ที่ คน และ Skill ของคนคนนั้น
  • อย่าพยายาม Mapping Role
  • ดูคนที่อยากเป็น SM (ระวังไว้นะครับ สุดท้ายถ้า Team Mature แล้วจะตกงานนะครับ)
  • เป็นสิ่งใหม่ครับ ไม่เคยมีมาก่อนในองค์กร เอาคนที่เป็นอยู่แล้วมาเป็น (อาจจะจากข้างนอก)

ปัญหาของการ Mapping Role ไม่ได้จบอยู่ที่ PM กับ SM แต่แม้กระทั่ง PO เองก็มีความเข้าใจผิดอยู่เยอะ เพราะหน้าที่นึงของ PO คือ Clarify Requirement พอพูดถึง Requirement ทุกคนก็จะหันไปมองหา SA หรือ BA ที่ทำหน้าที่เกี่ยวกับ การทำให้ Requirement มัน Clear อยู่ แล้วหยิบคนกลุ่มนี้มาเป็น PO เลย คำถามคือทำได้ไหม … ดูทีี่ Skill & Responsibility อีกนั่นแหละ แต่ส่วนมากมักจเอามาตรง ๆ ซึ่งผิด เพราะ SA หรือ BA ไม่เคยดูเรื่อง ROI ไม่เคยดูแลเรื่อง Budgeting เพราะฉะนั้น ในส่วนของหน้าที่ Clarify  Requirement ควรจะต้องทำร่วมกันระหว่าง Customer (เน้นว่า Real Customer) กับ Team

อีกเรื่องที่คนเข้าใจกันผิดเกี่ยวกับหน้าที่ของ SM ที่ 1 ในนั้นคือ removing impediments (ขจัดอุปสรรค) ให้กับ Team แต่การขจัดอุปสรรค ให้กับทีม ไม่ใช่ว่าจะเป็นของ SM เสมอ (นั่นไง …รู้สึกเสียว ๆ หลังอีกแล้ว) … ลองนึกถึงว่า ให้ SM ไป Search Google เพื่อหาว่าจะใช้ Library อะไรมาแทน Library เดิมที่ทีมบอกว่าใช้ไม่ได้ แล้วกำลังเป็นอุปสรรคกับทีมเนี่ย มันก็ดูแปลก ๆ นะ ถ้าจะบอกว่า Team นี้ Self-Managed เพราะฉะนั้นการกำจัดอุปสรรคที่ว่าคือ

  • Team หรือ Internal Impediment ต้องให้ทีมแก้กันเอง
  • Environment Impediment อาจจะให้ SM ช่วย

หมดแรงของวันนี้แล้ว 555+

มาถึงจุดนี้บอกตรง ๆ ว่าสมองผมล้ามากแล้ว ยังมีจุดสำคัญ ๆ อย่าง

  • Video ของ Terry Tate , Bas บอกว่าเป็นตัวอย่างที่ดีของ SM เลยนะ (ขำมากครับ)
  • 1 Fulltime ScrumMaster for 2 Team == 2 parttime ScrumMaster for 2 Team
  • ScrumMaster == หมาเลี้ยงแกะ, Team == แกะ
  • Legacy Code กับการทำ Scrum และผลกระทบทำให้กลายเป็น Dead Company ในที่สุด
  • Software Developer Secret Toolbox ซึ่งอันนี้ซึ้งน้ำตาไหล

จริง ๆ มีหลาย ๆ อย่างใน Class นี้ที่ผมไม่สามารถบรรยายออกมาเป็นคำพูดได้ครับ ยังไงเดี๋ยวคงต้องรอมีแรงเพื่อทำ Day 2 และ Day 3 ต่อไปครับ

Reference 

Advertisements

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s