ScrumMaster in Action (Day 1) – Introduce Agile and Scrum

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

โชคดีที่พี่หนุ่ม จาก สยามชำนาญกิจ เปิดคอร์ส “3 Days Workshop ScrumMaster in Actions with Prathan D.” ให้กับทางทีม KBTG ของธนาคารกสิกรไทย และมีเก้าอี้เพิ่มให้นิดหน่อย ก็เลยใคร่อยากไปรู้บทบาทที่แท้จริง และไปเพื่มความรู้เรื่อง Agile, Scrum ประดับความรู้เดิมอันน้อยนิดด้วย

(รูปภาพจาก Facebook – Prathan Dansakulcharoenkit)

วันแรกที่ได้เรียน คือเรื่อง คุณค่า 4 ประการและหลักปฏิบัติ 12 ประการของการพัฒนาซอฟต์แวร์แบบแอไจล์  (The 4 Values and 12 Principles of the Agile Manifesto) พี่หนุ่มเล่าถึงที่มาของเหตุการณ์ที่มีคน 17 คน แถลงการณอุดมการณ์แห่งแอจไจล์ 4 ข้อ จากนั้นอธิบายทีละข้อว่า ถ้าจะทำเหล่านี้ได้ ก็มีหลักการให้ปฏิบัติ 12 ประการ อาจจะทำไม่ครบก็ได้ แต่อยู่ที่เราจะหยิบนำข้อไหนไปประยุกต์ใช้กับทีมและองค์กรให้เกิดผลแบบแอจไจล์

(รูปจาก http://www.scrum123.com/diary/why-we-must-adopt-agile/)

(รูปจาก http://www.scrum123.com/diary/why-we-must-adopt-agile/)

เมื่อมาถึงจุดนี้ เกิดถามคำถามหนึ่งที่ทุกองค์กรต้องกลับไปคุยกันว่า..

องค์กรมีความชัดเจนขนาดไหนที่จะใช้ Agile

และที่ทุกคนในงานบอกปัญหาของตัวเอง (Pain Point) ก็มักจะเหมือนๆกัน คือ

ปัญหาจากการแปรรูป (Transitions) ของเดิมที่มีอยู่ เพื่อไปใช้ Agile โดยที่คนภายในและภายนอกสามารถยอมรับได้

(ไม่ได้ใช้คำว่า เปลี่ยน หรือ Change เนื่องจากท่านเหล่านั้นไม่มีใครยก Agile ไปทำแทนของเดิมเลย)

เกร็ดเพิ่มเติมจาก พี่หนุ่ม

• ไม่มีเครื่องมือใดๆ มาแทนทักษะของคนได้
• คุณค่า ของ Agile 4 ข้อ และหลักปฏิบัติ 12 ประการ ไม่ได้บอกว่า “ทำอย่างไร” (How) แต่บอกว่า ทำแล้ว “จะได้อะไร” (Value)
• ใน Core Value ข้อ 2 ใช้คำว่า Documentation ไม่ได้หมายถึงเอกสาร แต่หมายถึง สิ่งที่ทำให้เป็นประจักษ์ ซึ่งจะใช้ รูปภาพ, Workflow, Use Case, Mind Map อื่นๆ ได้หมด
• หลักปฏิบัติข้อ 9-11 เป็นเรื่อง Development ที่เกิดขึ้นได้ยาก แต่ถ้ามี 4 ข้อเสริมเข้าไปด้วย จะทำให้เกิดขึ้นได้ นั่นคือ
  • Coding Standard
  • Version Control + Commit Code บ่อยๆ
  • Comprehensive Testing (หมายถึง Dev Team ก็ต้องทำ Unit Test ด้วยนะ)
  • Build Automation
• ถ้าจะทำ Core Values ทั้ง 4 ข้อ ต้อง
  • Build Skill – ให้ความสามารถและความเข้าใจใกล้เคียงกันทั้งทีม
  • ปรับจังหวะการทำงานของทีมให้ลงตัวทุกคน และเข้ากับ Process
  • เอา User ให้อยู่ใกล้กับทีม (พี่หนุ่มแนะนำให้นั่งห้องเดียวกัน)
  • บริการจัดการคิวงานให้ดี

(รูปภาพจาก Facebook – Prathan Dansakulcharoenkit)

แล้วจะใช้ วิธีการทำงาน (Methodology) ใดล่ะ ที่สอดคล้องกับแอจไจล์..

ในปี 1986 มีลุงชาวญี่ปุ่นสองคนชื่อ Hirotaka Takeuchi และ Ikujiro Nonaka ได้นำเสนอคำว่า “Scrum” ในบทความชื่อ “The New New Product Development Game” ซึ่งเขาบอกว่ามันเป็นรูปแบบของการพัฒนาผลิตภัณฑ์แบบใหม่ (Product Development) ที่สามารถเพิ่มประสิทธิภาพในการผลิตและมีความยืดหยุ่นด้วย

ลุงทั้งสองยกตัวอย่างวิธีการพัฒนาผลิตภัณท์ (The Development Process) จากบริษัทในญี่ปุ่นและอเมริกา ซึ่งแยกออกได้เป็น 3 ประเภท

(รูปภาพจาก https://hbr.org/1986/01/the-new-new-product-development-game)

บริษัทที่ใช้ Type A ตัวอย่างเช่นองค์การ NASA ที่เป็นสายการผลิตแบบต่างคนต่างทำ โดยที่ไม่ได้รู้ว่าแต่ละส่วนใครทำอะไร (Liner)

บริษัทที่ใช้ Type B เช่น Fuji-Xerox ที่มีการทำงานร่วมกันเฉพาะในส่วนที่เกี่ยวข้องกัน

และสุดท้าย บริษัทที่ใช้ Type C เช่น Honda และ Canon คือทำงานร่วมกันในหลายๆขั้นตอน

จากนั้นคุณลุงทั้งสองก็ให้ข้อสังเกตว่า บริษัทที่มีการทำงานแบบมีประสิทธิภาพและยืดหยุ่น จะมีลักษณะเหมือนๆกัน 6 ข้อ คือ

1. Built-in instability
2. Self-organizing project teams
3. Overlapping development phases
4. “Multilearning”
5. Subtle control
6. Organizational transfer of learning

ซึ่งลุงแนะนำว่า เราควรทำงานแบบที่ Honda ทำ เหมือนกับการเล่นรักบี้ ที่คนในทีมหลักๆ จะอยู่ตั้งแต่ต้นจนจบเกมส์ ทำหลายหน้าที่ร่วมกัน จนส่งลูกรักบี้ไปสู่จุดหมายได้

ต่อมา Ken Schwaber ได้ศึกษาหลักการของลุงชาวญี่ปุ่นสองคน และในปี 1995 เขาร่วมกับ Jeff Sutherland ได้เผยแพร่เอกสารชุดหนึ่งชื่อ SCRUM Development Process เพื่ออธิบาย วิธีการทำงานแบบสกรัม (Scrum methodology) โดยเล่าตั้งแต่รูปแบบของ Waterfall, Spiral และ  Iterative จนทำให้เกิดการพัฒนาเป็น Scrum ขึ้นมา (เป็นเอกสารลำดับแรก ที่พี่หนุ่มให้อ่านก่อนเข้าเรียนคอร์สนี้)

(รูปจาก http://www.jeffsutherland.org/oopsla/schwapub.pdf)

จากนั้น ได้มีเอกสาร The Scrum Guide เผยแพร่จากสองท่านนี้ออกมาเรื่อยๆ ตั้งแต่ 2011, 2013 จนเป็นเวอร์ชั่นล่าสุดคือ The Scrum Guide (July 2016) (เป็นเอกสารลำดับที่สองที่ควรอ่าน – Changes)

ที่ต้องบอกเล่าประวัติศาสตร์กันเป็นวรรคเป็นเวร เพราะ “Scrum Master” ควรจะต้องเป็น “Master of Scrum” คือ “ต้องรู้จักสกรัมเป็นอย่างดี” และอธิบายให้คนอื่นเข้าใจได้

แล้ว สกรัม คืออะไรล่ะ ในส่วนนี้ผมจับความจากพี่หนุ่มไม่ทัน แต่ขอแปลมาจากเอกสาร The Scrum Guide ที่ให้นิยามไว้ว่า เป็น “รูปแบบการทำงานที่ช่วยให้ทีมจัดการกับปัญหาที่ซับซ้อน โดยที่ยังส่งมอบงานได้อย่างมีประสิทธิภาพ สร้างสรรค์ และเกิดประโยชน์สูงสุด ” (Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.)

(ภาพจำลองของ Scrum ในปี 1995)

และก็ต่อด้วยประโยคแบบค่อนข้าง Abstract เล็กๆ คือ

• Scrum is Lightweight
• Simple to understand
• but Difficult to be master…

(ตัดฉากไปที่ความเงียบ และมีนกบินผ่านสามตัว)

ด้วยรูปแบบของ Scrum Methodology นี้เอง จึงทำให้มีผู้หยิบไปประยุกต์เพื่อให้ได้ Agile 4 ข้อ และเป็นไปตามหลักปฏิบัติ 12 ประการ

ถ้าสังเกตดีๆ จากภาพ Scrum Methodology, ช่วง Planing และ Closure ได้ยกตัวอย่างว่าใช้ Waterfall นะครับ (หรือจะใช้วิธีการใดก็ได้) ซึ่งค่อนข้างขัดแย้งกับความรู้หลายคนที่มักมอง Waterfall เป็นปีศาจทำโปรเจ็คล่ม เลยหันมาหาเทพเจ้า Scrum

ขอย้อนกลับไปอธิบาย Waterfall อีกครั้งว่า เราใช้มันครบหรือเปล่า

ซึ่งจริงๆ แล้ว Waterfall มันใช้งานได้ และมันก็ถูกใช้ทำงานมาตลอดในหลายอุตสาหกรรม จนมีบุคคลท่านหนึ่งชื่อ Dr. Winston Walker Royce (หรือ Dr. Royce) แกได้เจอปัญหาว่าเฟส Testing ของ Waterfall เป็นปัญหาเยอะที่สุด แต่พอสาวย้อนไปหาสาเหตุจริงๆแล้ว มันมาจากเฟส Coding  แล้วที่ Coding มันเพี้ยน ก็เพราะช่วงออก Software Requirement มันมีปัญหานั่นเอง

ซึ่ง Dr. Royce แกเลยปรับปรุง Waterfall ใหม่ จนปี 1970 แกได้ออกเอกสารชื่อว่า Managing the Development of Large Software Systems ซึ่งอธิบายการปรับปรุงของแกไว้ ตามภาพด้านล่าง

(รูปจาก http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf)

ซึ่งในปัจจุบันที่เราไปโวยวายว่า Waterfall ไม่ดี เพราะเราไม่ได้ทำเต็มรูปแบบของมัน ตามที่  Dr. Royce ได้ปรับปรุงไว้ (และดูเหมือนจะไม่มีใครสอนให้ทำด้วย) คือ

1. Program Design Comes First – เราควรออกแบบโปรแกรมตัวอย่าง (Phototype) ออกมาให้เห็นก่อน ซึ่งมันจะแทรกอยู่ระหว่างขั้นตอน Software Requirements phase และ Analysis phase ซึ่งในเอกสารของ Dr. Royce บอกว่า
   – ทำโดยดีไซน์เนอร์นะ ไม่ใช่โปแกรมเมอร์หรือนักวิเคราะห์ระบบ
   – ออกแบบการทำงานแต่ละส่วน ไม่ว่าจะเป็น processing, functions, data base, data base processing
   – เขียนมันออกมาเป็นเอกสารที่ทุกคนเข้าใจได้
2. Document The Design – เขียนเอกสารออกมาให้เข้าใจง่าย (Simple) และตกลงร่วมกันว่าจะใช้เป็นมาตรฐาน
3. Do it twice – คนทำงานและลูกค้า พิจารณาของที่ได้มาในข้อ 1 และ 2 เพื่อรีวิวและปรับปรุง จากนั้นทำขั้นตอนเดิมอีกรอบ เพื่อให้ได้ของตามต้องการ และจัดทำเป็นเอกสารกลับเข้าไปเพื่อทำงานในแต่ละขั้นตอนต่อไป
4. Plan, Control and Monitoring Testing – ทำแผน และก็เน้นเรื่องการทดสอบซะ เพราะมันเป็นจุดที่ทำให้เสียเงินเยอะที่สุด หากมีข้อผิดพลาด
5. Involve The Customer – นำเสนอข้อมูลของการผลิต และให้ลูกค้าได้ชมของ (อย่างเป็นทางการ) ก่อนที่จะส่งมอบไปให้เขาต่อไป (คงประมาณว่ายืนยันคำสั่ง และของที่ได้รับ)

(รูปภาพจาก Facebook – Prathan Dansakulcharoenkit)

กลับมาที่รายละเอียดของ Scrum

หลังจากได้เข้าใจที่มาและความหมายของ Scrum พี่หนุ่มจึงพาลงไปในรายละเอียดว่า Scrum ต้องประกอบด้วยอะไรบ้าง

โดย Scrum มีองค์ประกอบ 3 ประการ คือ

1. Iterative and Incremental – คือทำงานเป็นรอบ
2. Lean (TPS – The Toyota Production System) – คล่องแคล่ว
3. Timebox – มีกำหนดเวลาชัดเจน

โดยทีมที่ทำ จะเรียกว่า Scrum Team ซึ่งจะมี 3 บทบาท (Scrum Roles) คือ

1. Product Owner (PO) – เจ้าของงาน (ผลิตภัณฑ์)
   1. เป็นผู้รวบรวมไอเดีย หรือรับโปรเจ็ค เข้ามา จัดทำเป็น User Story และประสานกับทีมเพื่อให้ทีมทำ Product Backlog
   2. Product Owner ไม่มีหน้าที่เขียน Requirement, Product Backlog ยกเว้นเป็น Product ตัวเอง หรือสามารถทำเองคนเดียวได้, ซึ่งปกติแล้วจะต้องมีทีมช่วยกันทำ หรือ Development Team ช่วยทำ
   3. Product Owner ทำงานคนเดียวไม่ได้ ต้องมีทีม เพราะไม่มีใครรู้ดีทุกอย่าง บางอย่างต้องใช้ผู้เชี่ยวชาญ (Domain Expert) ในด้านนั้นๆ
   4. Product Owner เมื่อถึงเวลาให้จัดลำดับ Product Backlog เข้า Sprint ควรแนะนำให้เขาเรียงตาม Bussiness Value โดย Features ต่างๆ ให้อ้างอิงจาก Learn, Earn, Save ถ้าตอบไม่ได้ ให้พิจารณาร่วมกับ KPI ของบริษัทว่าทำแล้วตอบโจทย์ตัวไหนของธุรกิจไดบ้าง
   5. เทียบ Product Owner เหมือนเซียนหวย ที่กำลังจะลงทุน 80 บาท แล้วต้องได้สามล้านกลับมา คนเหล่านี้เขาต้องไปหาข้อมูลตามสำนักตามข่าวต่างๆ ถึงจะไปเลือกซื้อได้
2. Development Team (Team) – ทีมพัฒนางาน และส่งมอบงาน (ผลิตภัณฑ์)
3. Scrum Master (SM) – ผู้ดูแลทีม และให้ทีมดำเนินกิจกรรมต่างๆ จนบรรลุเป้าหมาย
   1. ไม่ใช่ ผู้จัดการ (Manager), ผู้จัดการโครงการ (Project Manager), หัวหน้าทีม (Team Lead), ตัวแทนทีม (Team Representative)
   2. Scrum Master จะเปรียบเสมือนหมาเลี้ยงแกะ และ Team เป็นแกะ ซึ่งหมาเลี้ยงแกะไม่จำเป็นต้องเข้าใจภาษาของแกะ แต่คุมให้เข้ากรอบที่ต้องการได้
   3. Scrum Master ต้องแยกเป็น Full Time Job เพราะมีหน้าที่ต้องดูแลทีมให้ทำงานได้
   4. Scrum Master ควรเข้าใจคน ตั้งแต่ระดับ Top Management ลงไปถึงคนทำงานระดับล่าง
   5. Scrum Master ไม่จำเป็นต้องตอบทุกคำถาม ในสิ่งที่ตนเองไม่รู้
   6. Scrum Master ต้อง Conduct, Train และ Coaching Team โดยจะมี 3 บทบาทหลักๆ คือ
      • สร้าง Product Owner ที่ทำงานได้ (Work Well) – ถ้าทำไม่ได้ Scrum Master ต้องทำให้ดูได้
      • สร้าง Development Team ที่ทำงานได้ – ถ้าทำไม่ได้ Scrum Master ต้องทำให้ดูได้
      • ปรับองค์กรให้เป็น Scrum (ถ้าต้องการเป็น Scrum ทั้งองค์กร)

(กราฟสรุปสิ่งที่ Scrum Master ต้องใช้เวลาและใส่ใจ)

ซึ่งสมมติว่าได้ทีม และ Requirement ของงานที่จะทำแล้ว จนแจกแจงเป็นชิ้นงาน  (Product Backlog Item) เสร็จแล้ว รูปแบบการทำงานของ Scrum ก็จะทำงานเป็นรอบ ซึ่ง 1 รอบ หรือเรียกว่า 1 Sprint โดยจะใช้เวลา Sprint ละ 5, 10, 15, 20 วัน แล้วแต่ทีมตกลงกันว่าเวลาใดสะดวก โดยพี่หนุ่มแนะนำจากประสบการณ์ว่าใช้เวลา 10 วัน กำลังดี ไม่มากและไม่น้อยไป

และในแต่ละ Sprint, ทีมจะต้องทำให้ครบ 6 กิจกรรม (Scrum Activities and Artifacts) ดังนี้

• Sprint Planning Part I – PO เลือกชิ้นงาน (Product Backlog Item) ที่จะให้ Team ทำใน Sprint โดยดึงงานออกมา พร้อมลำดับความสำคัญ
• Sprint Planning Part II – PO,Team ประเมินวิธีการทำของ Task ต่างๆ จนได้ออกมาเป็นข้อมูลที่พร้อมทำงาน ซึ่งจะเรียกว่า Sprint Backlog, รวมถึง PO และ Team ต้องตกลงสิ่งที่จะส่งมอบเมื่อจบ Sprint นี้ร่วมกัน (Potential Shippable Product Increment) หรือ อาจจะกำหนดเป็นนิยามของคำว่า “เสร็จสมบูรณ์ (DoD – Definition of Done)” ร่วมกันก็ได้
• Product Backlog Refinement – Team แปรรูป Product Backlog ให้เป็นชิ้นงานร่วมกัน
• Daily Scrum – Team,SM (และ PO) ประชุมร่วมกันทุกวัน เพื่ออัพเดทความคืบหน้า งานที่เสร็จ งานที่จะทำ ปัญหา
• Sprint Review – PO, Team รีวิวงานที่เสร็จใน Sprint ว่าเป็นไปตาม Potential Shippable Product Increment หรือ DoD ไหม
• Sprint Retrospective – Team, SM มองย้อนกลับไปในสิ่งที่ทำในรอบ Sprint ว่ามีอะไรดี ไม่ดี และต้องพยายามปรับปรุง
  • หลักการทำ Retrospective มี 5 ข้อ
    • มองกลับไปที่ตัว Product
    • มอง Process ที่ใช้อยู่
    • มอง Peoples (Team, Product Owner)
    • มอง Tools ที่ใช้อยู่
    • มอง Relationship ที่เป็น ทั้งภายในทีม และภายนอกทีม (Internal, External)

(รูปอธิบาย 3บทบาท 6กิจกรรม ของ Scrum)

โดยแปลงเป็นรูปสรุปสวยงาม จะได้ประมาณนี้

(รูปจาก http://scrumprimer.org/anime)

พี่หนุ่มคอยเพิ่มเติมเกร็ดต่างๆ Agile ระหว่างการสอนอยู่เรื่อยๆ ตามเท่าที่ได้จากประสบการณ์

• Agile บอกว่า Welcome Change แต่ไม่ได้บอก Manage Change แบบ Scrum, ITIL
• ทีมต้องมีความรู้สึกเป็นเจ้าเข้าเจ้าของ Product ที่ตนเองถือ
• Agile ไม่ใช้คำว่า “ใช้” ใช้คำว่า “ประยุกต์”
• ไม่มีคำว่า Full Agile เพราะอยู่ที่เราประยุกต์ให้เข้ากับองค์กร
• ให้เอาวิธีการทำงานเดิม (SDLC – Software Development Life Cycle) ปรับเข้าใช้กับหลักปฏิบัติ 12 ข้อ อย่าพยายามเอา SDLC ไปยัดลง 12 ข้อ

เกร็ดอื่นๆในส่วนของ Scrum

• รูปแบบการสร้าง Scrum Master ต้องพาเขาไปได้รับประสบการณ์จริง และประกบสอนไปเรื่อยๆ เพราะแต่ละคนมีพื้นฐานมาไม่เท่ากัน การเข้าใจและนำมาใช้ต่างกัน เสมือนที่ Padawan ต้องตามประกบ Jedi ในเรื่อง Star Wars
• อย่านำ Project ลูกค้ามาทดลองทำ Scrum
• Top Management ควร Support เพื่อให้งานลื่นไหล
• อย่าพยายามสร้าง Self-Organize Team แต่ให้สร้าง Self-Managing คือ
  • วิเคราะห์ + วางแผน + แตกงาน
  • Monitor + Manage Progress
  • Monitor + Manage Process
• ถ้าจะ Adapt Agile ให้เอาหลักปฏิบัติ 12 ข้อเป็นตัวตั้ง และสร้างทีม
• ในทุก Project ตัวที่ Fix มี 3 อย่าง คือ
  • Scope
  • เงิน
  • เวลา

จบวันแรก ปูทางภาพกว้างมาครบหมด อัดแน่นมาก แต่ก็เติมความรู้ Agile, Scrum เข้าหัวได้มากเช่นกัน พี่หนุ่มมักถามบ่อยๆตลอดการสอนว่า

แล้วยังอยากเป็น Scrum Master อยู่อีกไหม?

นั่นสิ ยังอยากเป็นอยู่อีกไหม?!! ไว้ไปเรียนต่อวันที่สอง..