[ATH2022] สรุปงาน Agile Thailand 2022 (Agile ในชีวิตจริง)

  • งานนี้เริ่มต้นจาก Facebook Page AgileThailand มีแจกบัตร ผมกดทันรอบแรกนะ วิ่งอยู่ในฟิตเนสพอดี 555 จากนั้นมีแจกบัตรอีกหลายรอบ รวมถึงมีกิจกรรมต่าง เช่น การเป็น Speaker หรือ จะ Blog สรุปก็ได้นะ

การเดินทาง

  • ปีนี้สะดวกดีครับ นั่งสองแถวจากบ้าน และ MRT บางขุนนนท์ และยิงยาวมา ศูนย์การประชุมแห่งชาติสิริกิติ์ครับ

มาถึงงาน

  • ตอนแรกมาถึง 8 โมงคิดว่ามาเข้าและ มีคนมาเช้ากว่าอีก งานนี้มีคนสนใจเยอะมากครับ
  • สำหรับงาน Model งานบุญ ผมชอบคำนี้ของคุณปอมนะ มีอะไรทุกคนก็ช่วยกัน และแกแชร์เรื่องของการก้าวออกมาออกกำลังกาย มันต้องเริ่มจากเปลี่ยนคำว่า เราไม่ไหว ทำไม่ได้ ค่อยตั้ง Goal เริ่มจากที่ละนิด โดยมี อ ชัชชาติ เป็น Inspiration และใครสร้างแรงบันดาลใจได้นะ

Agile in Bitkub (เก่ง Bitkub)

  • เริ่มต้นเหมือนชมรมคอม โตมาเรื่อยๆ ขยับขยายที่ตั้งย้ายที่มา จนมาถึงที่นี่ FYI Center
  • พนักงาน 10 คน มา 1600 คน (Customer Support 800 คน)
  • รายได้ปีแรก 30 ล้าน > 300 ล้าน และ ปี 3 3000 ล้าน โตประมาณ 100 เท่า ซึ่งเป็นการโตมาจากปรับวิธีคิดให้ตอบสนองกับการเปลี่ยนแปลงที่ไว ถ้าทำแบบเดิมเราจะไม่สามารถ Growth โดยการ Growth แบ่งได้ 3 State ดังนี้
  • State แรก War time
    • คน เงิน เวลา จำกัด นึกภาพเกม Survival ที่แบบต้อง ประกอบเครื่องบินให้ทันหนีจากการล้มตาย การบริหารช่วงแรก take control / no time ดังนั้นต้องการคนสั่'การได้ดี และคนทีรับคำสั่งได้ตลอดเวลาต้องคิด Strategy ว่าอะไรที่สำคัญที่สุดสำหรับสร้างองค์กร ไม่ทัน Layoff / ตายจากไป (อย่างตัว ฺBitkub เคยเกือบถึงจุดที่ funding เหลือ 2 เดือน ต้องปรับ Strategy กับ Deal กับ Investor ให้ทัน)
  • State 2 Scale-up
  • State 3 Peace Time
    • ปรับองค์กรให้เป็น long-lasting company แม้ว่า founder ไม่อยู่และ ยกตัวอย่าง Walt Disney
    • ปรับ culture จากเดินคนบอกเวลา เป็นคนสร้างนาฟิกา ใน Agile จะเป็น Self Owner ship/ self organization มีคนมาสานต่อเจตนารมณ์ได้ต้องหา right people / right time
  • NOTE: Keyword War time / Peace Time ลองดู CEO ยุคสงบ ปะทะ CEO ยุคสงคราม | Mission To The Moon EP.1574 - YouTube กับ CEO: The Peacetime VS Wartime เพิ่มได้ครับ
  • สุดท้ายนึกถึง bitcoin คิดถึง Bitkub

จากนั้นเป็นช่วง pitch เนื้อหาของ speaker สั้นๆ คนละ 20 วินาที และอธิบายกฏ

  • Unconference
    • Open space คนที่มาคือคนที่ใช่ สิ่งไหนเกิดขึ้นแล้ว สิ่งนั้นดีเสมอ เริ่มเมื่อพร้อมจะเริ่ม จบเมื่อพร้อมจะจบ
    • Law of two feet: ถ้าพบว่าตัวเองไม่ได้สนใจ เรียนรู้ หรือ ทำประโยชน์ได้ สามารถใช้สองเท้าพาตัวเองไปที่อื่นได้ โดยไม่เป็นการเสียมารยาท
  • หัวข้อที่แชร์กันในงาน
  • สำหรับหัวข้อที่ผมได้เข้าฟัง มีตามด้านล่างนี้เลยครับ

Agile Discovery ชอบ ไม่ชอบตรงไหนบอกที by Na ExxonMobil

  • Transformation Cycle - Discovery จุดเริ่มต้นการทำ transformation
    • Intake ทำไปทำไม ได้อะไร
    • Readiness check พร้อมไหม
    • Discovery ทำความเข้าใจ มีปัญหาอะไร
    • Deliver เริ่มเปลี่ยน
    • Support ทำให้เกิด sustain continuous improvement
    • Handover ส่งต่อให้คนในองค์กรดูต่อไป (กรณีที่เป็น Consult)
- Intake
  • Stake Holder Overview
    • step แรก change management ใครกระทบ เดิมมีปัญหาอะไร แก้ pain point ไหม จริงๆ agile ช่วยไหม แต่ละ role มองในมุมที่ไม่เหมือนกัน
    • แล้ว goal ที่อยากได้ คือ อะไร
    • Obstacles ปัญหาที่มี อยากได้อะไร
    • Assumption อะไรที่เป็น fact อะไรเป็นสมมติฐาน
  • Self Assessment ตรวจสอบ 2 มุม
    • Knowledge - จาก training วัดเน้นให้เกิด self-refection โดย
      • รายบุคคลทำ Test จาก Open Assessments | Scrum.org จะได้รู้จริงๆว่าเข้าใจจริงไหม
      • Team Assessment ตกลงการวัดก่อน เช่น มุมที่สนใจ Outcome / Ability to Improve และ Speed จากนั้นมีคำถามให้วัดในแต่ละมุม
    • แต่ต้องลองทำให้เกิด Experience เพราะบางทีรู้แล้ว จะได้ปรับวิธีการทำให้ดู (Mentoring) จากนั้นให้ลองทำ และ Feedback วัดจากการ สัมภาษณ์ พูดคุย สังเกตุ การทำงาน
  • หมวกที่ต้องสวม
    • Teacher - สอน
    • Facilitator - นักประสาน support ทุกฝ่าย
    • Consult - ดูบอกปัญหา และ Recommend
    • Mentor ทำให้ดู จากนั้นให้ลองทำ
    • Coach พัฒนาคน
  • Q&A
    • Q:Training ถ้าเริ่มใหม่ๆเลย Training ถึงขั้นไหน
      A: เริ่มจาก basic agile mindset ก่อน และจากนั้น role เจาะตาม framework
    • Q: ยกตัวอย่างแบบปัญหา top 3 ของ agile
      A: 1. ใช้ไปนานๆ ทำ agile เป็น process / 2. เปลี่ยนไปทำไหม meeting ดูเพิ่ม งานดูเยอะ / 3. People / 4. Pull งานไม่ได้ตาม priority ต้องมาปรับการทำงานทำข้อตกลงก่อน
- Readiness check
  • Purpose เรามีเป้าหมายเดียวกันไหม
  • Expectation ทำได้จริงไหม เช่น เอา Agile 3 เดือน แล้วเร็ว 3 เท่า มัยทำได้จริงไหม มันจะกลายเป็นว่า ถ้าไม่ตรง Expectation จะผิดหวัง และอาจจะทำให้ Transformation ไม่รอด
  • Commitment - จะทำได้ไหม เช่น จะสร้างกล้ามเนื้อเรามีเวลามา gym ไหม
  • Investment - มีเงิน เวลาไหม
  • Motivation - พร้อมไหมมม
  • Note
    • Agile ทำให้คนปรับเร็ว ต้องดูงานว่าวิธีการเดิม Serve need ไหม เช่น งาน routine มี solution และ อาจจะไม่ต้องไปรับมันนะ
    • Agile ไม่ใช่การแจกงาน และทำงาน Priority ไม่ make sense

- Agile Discovery

  • จาก Intake + readiness รู้ Current State ต่อไป
  • Research เก็บข้อมูล จาก
    • ต้องเลือก persona ให้ถูก และ อย่าเอาความคิดตัวเองใส่ลงไป
    • User Interview ให้เข้าใจ Goals / Pains / Gains ของแต่ละกลุ่ม อาจจะทำเป็น Open Question และบางทีเราจะได้ Solution จากคนในองค์กรเองแหละออกมา หรือได้ Insight เน้น Anonymous สบายใจจะพูด
    • Gemba walk เข้าไปดูสังเกตุการณ์ go see / ask why ให้รู้ก่อนมาดูทำไหม / show respect เคารพกับทีม
    • Note ตอนนี้อาจจะเจอแบบว่าคนอายุงานเยอะ ไม่อยากใช้ agile เค้าไม่อยากเปลี่ยน ต้องจูนให้เข้าใจเป้าหมาย และรู้ว่าเปลี่ยนเพื่ออะไร ดีอย่างไร คนไม่เข้าใจ the why / why we have to change
  • Synthesis grouping หา Goals / Pains / Gains จาก Research มา ตอนทำ อาจจะใช้ post it จับ quote เป็นกล่องๆ จะได้มา Grouping ได้
    • Why
    • What
    • How
    • Report Out - บอกจุดที่ต้องปรับปรุง / gap / positive evident
  • Report out with user journey ยกตัวอย่างองค์กรที่แบ่งคนมาเทรน หลายกลุ่ม
  • แต่ทว่า Feed-Back แต่ละรอบต่างกัน แยกเป็นกลุ่มทำให้ไม่เข้าใจตรงกัน กลุ่มหลังๆ ที่เข้ามาทำไมต้องมาในจุดนี้ด้วย รู้สึกว่าไม่ Stable
  • สุดท้ายแก้ยังไง set vision mission ให้ชัดเจน เพิ่ม sense of purpose มีกลยุทธ์ชัด และทำ Team Builder
  • Role and Responsibility ที่สำคัญที่สุด Agile Team
  • Transformation via System thinking Lens - Balancing Loop มุมมองการนำเสนอข้อมูล Cause and Effect ถ้าไปปรับ Node เพิ่มขึ้นจะมีผลอะไรบ้าง

หวย online กับ agile (Infinitas by krungthai)

FACT นี้สำคัญมาก ถ้ามีหวยเป๋าตังค์ มีการ์ดทอง คือ ถูกหวย (เพิ่งรู้จริงๆนะ)

<< เราต้องรอลุ้นต่อไป 5555 >>
- Fact ของพัฒนาหวยออนไลน์ (เป๋าตังค์)
  • งานร้อน 1.5 เดือน (รวมวันหยุด)
  • Project ที่ Impact มากๆ กับทุกคน
  • มาแบบวิธีพิเศษไม่ได้ผ่าน Process แบบราชการปกติ
  • ระบบเดิม จองสลาก ที่เป็น monolith ที่ design มาจองสลาก แต่มันไม่รู้จัก digital lotto scale แตะไม่ได้
    ระบบใหม่ microservice + blockchain
  • Stack Holder ผู้ซื้อ (เป๋าตังค์) / ผู้ขาย (ถุงเงิน) / กองสลาก(ระบบหลังบ้าน) / KTB (Payment Gateway+การผูกบัญชีขึ้นเงิน) เป็นต้น
  • ตัวสลากมันต้องมีตัวจริงนะ กฏหมายมันบังคับ
  • Agile แบบ Adapt ตาม Constraint ข้างต้น
- เริ่มต้นยังไง ?
  • Domain Driven Design หา Domain ที่เกี่ยวข้อง แยกออกมา 7 ส่วน
  • จากนั้นจัดทีม 7 squat ให้เสร็จใน 1 วัน key ผู้บริหารให้อำนาจเต็มที่ ใช้เท่าไหร่ได้หมด
- ปรับอะไรไปบ้าง
  • เครื่องมือ
    • Miro board - รวมทุกอย่างหมด ทั้ง brain storm / flow / plan / API / document
    • Discord - การสื่อสาร
  • Requirement
    • เอา Happy Flow มากางคุยให้เห็นภาพตรงกัน
    • BA กับ Dev มาคุยเพิ่ม Case แปลก หรือ Technical Case อื่นๆที่อาจจะเกิดขึ้น
  • Daily Sync ใน Discord ทุกคน 30 นาที 100 คน ยากนะ คนละ 20 วินาที ท้าทายไปนะ ปรับอย่างไร ?
    • กำหนด Key Man มา Facilitate
    • เอา Lead BA DEV มาคุยและให้คนอื่นมาเสริม เช่น อาจจะถาม Dev ทุกดูมาเพิ่มเลยจะเรียกว่า Scrum of Scrum ก็ได้นะ
    • พอเอามาคุยด้วยกันสั้นๆ จะให้เห็นภาพเข้าใจตรงกัน
  • Role + Response ปรับ skill + cross function
    • ไม่มี scrum master ใช้ pm แทน
    • BA - Test ตรงเลย อาจจะผ่าน Postman
    • Dev - ต่อรอง Requirement
    • QA - App Design + Message Code เน้น Manual Test เพราะมันเร่ง รอบหลังๆมาเพิ่ม Automate
  • Integration Problem ทำไมหละ
    • เข้าใจไม่ตรงกัน
    • Communication Gap
  • Deploy และ
    • เปิดขายวันแรก 16 June ซ้อม 5000 ขายจริง 5 ล้าน
    • Social Media Monitoring Tool ที่น่ากลัว - บาง Bug Report จากตรงนั้น
  • Retro ทำหลังปิดงาน มีทั้งด้าน
    • ดี เช่น รู้ DevOps ทั้ง Flow / Value สุดๆ ผูกบัญชี คนมาเปิดบัญขีเยอะ
    • และไม่ดี Burn Out งานเผา แก้ยังไง long vacation 15 day++ (อันนี้ดีส่วนตัวไม่ค่้อยได้เท่าไหร่ หลังเผางาน) / reward จากผู้ใหญ่มาเลย / workcation หรือจัดกิจกรรมอื่นๆ
- ปิดท้ายและ

มัน Agile ไหมนะ Agile การปรับเปลี่ยน มันเข้ากับหลัก ดังนี้

  • Individual and interaction - ลด Process ได้ตัดหมด
  • Work Software - ไม่ได้มีเอกสารเยอะแยะ
  • Customer Collaboration มีการให้ End User ลองจริงๆ เช่น ผู้พิการ
  • Responding to Change - อ้าวให้ขายเพิ่ม มีการปรับระบบ ทำได้
- Lesson Learn
  • Team work
  • Leader - senior และ middle management ต้องการตัดสินใจ ที่เร็ว ช่วย และ Support
  • Trust - ในทีม และระหว่าวทีม
  • Customer Centric
  • Expectation - เข้าใจ management และ management เข้าใจเราด้วย
  • Motivation - ต้องส่งให้ทีม ให้รอดภายใน 1,5 เดือน
- Q&A
  • Q: Integration เจอปัญหาทำอย่างไร
    A: แก้โดยเอาทุกคนมาไล่ Flow ใน Discord และถาม และทีม
  • Q: ปัญหาใหญ่ที่สุดที่เจอ
    A: Technical View monolith > microservice และบางทีไปลองหน้างานเจอปัญหาแปลก Test เองไม่เจอ แต่ลูกค้ามีอะไรแปลกจนมาพบว่า bandwidth ไม่พอ เป็นต้น
    Business View การสแกนสลาก ใข้แบบดิจิตอลไม่ได้นะ มันติดกฏหมาย
  • Q: คุม spec ยังไง ?
    A: มีโครงที่เป็น resource กลางขององค์กรยังไง API Standard / Coding Standard
  • Sprint นับไง Dev Sit UAT - mini waterfall
  • Q: Scrum of Scrum มี dependency และ conflict จัดการยังไง
    A: ให้คุยกันตรงนั้นระหว่าง Daily Sync หรือ หลังไมค์ได้นะ หรือไม่คุยทีม lead เองได้

Theory of Constraint ทฤษฏีการอยู่คู่กับข้อจำกัด by Salah Chalermthai

  • เป็นส่วนนึงการทำ Lean Thinking โดยที่ Lean goal - remove waste / increase customer value / continuous improvement / respect for people
  • 7 Wastes of Lean
    • Motion - action ที่ไม่จำเป็น และเกิด value โรงงานลด flow การเดินทาง
    • Transportation
    • Over Production ทำมาเกิน ไม่มี requirement เกิด waste
    • Defect
    • Waiting - รอแล้วไม่ได้วาน
    • Over Process - ทำมากความจำเป็น
    • Inventory -
  • 7 Wastes of Lean (Software)
    • Motion / Transportation - meeting ไม่จำเป็น / algorithm logic
    • Over Production - waterfall
    • Defect - bug
    • Wait - รอทุกอย่าง buttock
    • Over Process - over engineer เอา tool มาใช้แล้วไม่คุ้ม เป็นต้น หรือทำมาเกินไป เช่น PenTest ทำทุกรอบตอน Test ข้างใน (คนในมุม Sec มาอ่านจะบ่นไหม 55)
    • Inventory - work not release ไม่เกิน value
  • ทุกองค์กรมีข้อจำกัดของตัวเอง แล้วเราจะทำอย่างไรทีจะอยู่กับ Constraint ได้
  • จาก Clip the fastest way to empty a bottle ตัว Constraint คือ ปากขวด ที่น้ำไหลออกช้า เพราะอากาศเข้าไปแทนที่ไม่ได้ (มี chaos อยู่) โดยวิธีเทน้ำออกมี 3 แบบ
    1. เปิดฝา - เทตรงๆ
    2. หมุนระหว่างเท
    3. ใส่หลอด - กำหนดทางให้อากาศเข้าไปได้
  • ทั้ง 3 วิธีเราแก้ปัญหา โดยอยู่กับ Constraint หมดนะ จะมองว่า Constraint เป็น bottleneck
  • กลับมาโลกของเรา ต้องมาดูภาพรวมว่า bottleneck อยู่ที่ไหน เช่น develop / test โดยวิธีการ
    1. Identify Constraint / bottleneck ก่อน
    2. Exploit Constraint ทำให้ bottleneck flow ที่สุด จนทำให้ให้มันเต็ม Capacity ของมัน อย่างตัวอย่างขวดน้ำ จะเป็นการหมุนระหว่างเท ถ้ามองเป็นการทำงานเหมือนจุนให้ทำไปใน Alignment เดียวกัน ทางเดียวกัน หรือจะปรับpull system - รอให้ bottleneck พร้อม และดึงงานออกมา)
    3. Subordinate Constraint ปรับกระบวนอื่นๆ ให้สอดคล้องกับ bottleneck ที่ปรับไปอย่าทำอะไรให้ขัด constraint
      Note Local optimize ตัวเองอยู่ - ทำไปแล้ว Flow งานเดิมมันยุ่งยาก หรือป่าว กลายเป็นเพิ่ม Constraint ใหม่ขึ้นมา
    4. Elevate constraint / de-bottleneck ทำให้ Constraint ลดลงหายไป ช่วงแห่งการลงทุน อย่างตัวอย่างขวดน้ำ เอาหลอดไปขวด หรืองานจริงของเราจะ เพิ่ม Server / skill คน
    5. Repeat step ไปแก้ bottleneck อื่นๆ
  • ตัวอย่างเคสอื่นๆ
    • Software - bottleneck ส่วน Test ใช้เวลานาน การปรับเอาตัว Automation มาช่วยลดเวลา ลด Manual อย่างรอให้งานมา หรือ Shift Left ขอให้ dev ช่วยทำ unit test
    • Operation - มี Data + Insight ขึ้นมาแล้ว มีคำแนะนำ แต่ไม่ใช้งานริง เพราะ คนที่ทำ Operation มองว่าไปเพิ่ม process ของเค้าอีก ไม่มีเวลาดู ถ้าจะ Improve ได้ ต้องไปช่วยเค้าแก้ปัญหา bottleneck ที่ไม่มีเวลาดูก่อน แล้วค่อยมา Improve งาน Operation ต่อ
    • Business Process
      • ตัวระบบ Payment Gateway ต้องมา Reconcile ว่าเงินเข้า ออกเท่ากันไหม บัญชีต้องตรวจสอบก่อนว่าเงินเท่ากันนะ ถึงจะโอนต่อได้ ตรงนี้ Inventory ขึ้น ถ้าปรับแนวคิดใหม่ ถ้าเงินโอนมา มากกว่าเงินที่ต่างจ่ายออกไปให้เดิน Flow ไปก่อน แล้วมา Reconcile อีกที
      • งานบัญชีมันต้องเป๊ะๆ ถ้าเงินเกิน 0.05 ต้องหาที่มาให้ได้ มันทำให้เสียเวลา หรืออาจจะเกิดการรอขึ้น อันนี้ policy มาถ้าจำนวนไม้เกินเท่านั้น เท่านี้ ให้ leave ไป
    • General Case การรอคิว ถ้ารอนานๆไม่ดี เรารู้ bottleneck แล้ว บอกเวลาประมาณไหม หรือบอกลูกค้าไปเลยว่าปิดรับแล้ว ลูกค้าจะได้ไม่เสียเวลารอ แล้วค่อยหาวิธีการมาเพิ่ม Capacity

Remote First Internal communication

- เมื่อไหร่คุย เมื่อไหรพิมพ์ จาก basecamp -
  • ข้อ 1 ถ้าไม่อยากสื่อสาร จะเป็นการสื่อสารรูปแบบนึง
  • ข้อ 2 พยายามทำงานให้มันเป็น async ใช้ textbase เช่น chat/document ลดงาน realtime เพราะใช้เวลาไม่จำเป็น
    ข้อ 15 communication ไม่จำเป็นต้อง sync เอาที่จำเป็นสั้น และชัดเจน
    NOTE: เคส time zone แก้ยังไง - กำหนดเวลาที่ติดต่อได้มา
  • ข้อ 3 ในการสื่อสาร พยายามเขียนที่ทำให้ละเอียด จด memo อย่างใน GitLab document everything live จะเปิด google doc ให้ทุกคนเขียน doc ร่วมกัน และการประชุมบอก agenda ชัดเจนใช้เวลาเท่าไหร่
  • ข้อ 4 ฉุกคิดสักนิดก่อนตอบ เพราะอิงข้อ 26 การรีบตอบไป อาจจะนำมาซึ่งหายนะ ยกตัวอย่าง เคสอาจารย์ชัชชาติที่ไปตรวจสำนักการระบายน้ำถามถึงลอกคลอง พอเจ้าหน้าตอบเป็นไป โดนแขวนเลย หรือ ถาม dev ใช้เวลาเท่าไหร่
  • ข้อ 5 meeting เป็นทางเลิอกสุดท้าย เพราะ อ้างอิงข้อ 13 meeting เวลาที่ใข้โดนทุกคน
  • ข้อ 6 chat ไหล อะไรที่สำคัญก็ไม่ควรอยู่ใน chat นะ ควรสรุปและย้ายไปที่อื่น สรุปสั้น ชัดเจน ทำไมถึงเลือก และมี trade-off อบ่างไร
  • ข้อ 7 พูดช่วยให้เข้าใจ ณ เวลานั้น แต่เขียนจดไว้ จะอยู่ได้ยาวกว่า อย่าง Gitlab มี wiki และ guideline การจดไว้ หรือทำ KM
  • ข้อ 8 เสริมจากข้อ 7 ระวังเรื่องของการตีความ ทำให้การเขียนมัน clear ชัด นิยามให้ชัดเจน เช่น unit test / integration test นี่แค่ไหนนะ ? หรือตัว requirement มี example ประกอบ
  • ข้อ 9 อย่าคาดหวังให้ใครตอบทันที เว้นแต่จะฉุกเฉิน
  • ข้อ 10 ย้ำตัวเองในเรื่องใหม่ๆที่ได้ทำ ไม่ใช่ทำแบบเดิม และผิดแบบเดิมไปเรื่อยๆ พอฟังหัวข้อที่ Theory of Constraint อะไรที่เป็น Waste โผล่มาเต็มตอนนี้ 555
  • ข้อ 11 commincationที่แย่ๆ สร้างภาระ
  • ข้อ 12 ปัญหาไม่ใช่การสื่อสาร แต่ความเข้าใจไม่ตรงกัน เช่น Definition of Done คือ อะไร ? อันนี้น่าจะต้องมี Step ในตรงลง protocol หรือทวนความเข้าใจกันไหม
  • ข้อ 14 แยก fact กับส่วนขยายให้ชัดเจน
  • ข้อ 16 now มันทำไม่ได้ แต่ควรรู้ว่าเมื่อไหร่ที่ต้องการ เช่น งานด่วน แต่ด่วนที่ใช้จริงไหม หรือด่วนแล้วคิดไม่ครบ Flow
  • ข้อ 17 พยายามหาคำตอบด้วยตัวเองก่อน ตามอย่าไปจี้ มองไปข้อ 7 ได้นัที่ต้องมีข้อตกลง และ KM กลาง
  • ข้อ 18 อะไรที่ไม่มั่นใจอย่าเพิ่ง Commit คิดก่อน พรุ่งนี้มันผลมันอาจจะคนละแบบกับที่คิดไว้เมื่อวานก็ได้
  • ข้อ 19 แต่ละคนมีการสื่อสารไม่เหมือนกัน เช่น บางคนเป็น Introverts ตอบน้อย หรือไม่ตอบเลย แต่เราต้องค้นหา หรือถาม เพื่อให้ได้คำตอบที่ชัดเจน แต่ถ้าไปถามจี้ตรงๆมันแปลก พยายามสร้างปฏิสัมพันธ์ให้มากๆ เพื่อให้มันไหลลื่น
  • ข้อ 20 ลองดูว่าบางเรื่องจำเป็นต้องสื่อสารไหม - คิดก่อนพิมพ์ บางคำอาจจะแรงไป
  • ข้อ 21 คำว่า ด่วน ด่วนที่สุด ไม่ม้อยู่จริง ดูตาม priority หรือ value ที่เกิด
  • ข้อ 22 สงสัยให้ถาม clear เงียบๆไปเดวลืม
  • ข้อ 23 นิยามคำที่ใช้ ว่าแค่ไหนอย่างไร
  • ข้อ 24 สื่อสารให้ถูกเวลา อะไรที่รอได้ มัน Link ไปกับข้อ 20 นะ อารมณ์แบบสั่งวันศุกร์เอาพรุ่งนี้ หรือที่ Peak ของผม โดนอยู่ ส่ง Merge มาศุกร์ เสาร์ อาทิตย์ ....
  • ข้อ 25 บอกข่าวดี กับข่าวร้ายให้ทิ้งช่วงกันนิดนึง หาช่วงเวลาให้เหมาะสม จะได้ไม่บั่นทอนกำลังใจของทีม
  • ข้อ 27 ไม่คุยปากเปล่า เพราะมันจะเพี้ยนไปเรื่อยๆ ระหว่างส่งสารต่อ
  • ข้อ 28 ทำให้ clear ให้ชัด หรือมี gap assumption อะไร
  • ข้อ 29 / 30 เลือกวิธีสื่อสารให้ถูกที่ ถูกเวลา ลด overhead ให้น้อยสุด
  • Basecamp work - พยายามสร้าง single source of truth ยกตัวอย่าง เช่น
    • Automatic weekly บอกว่าสัปดาห์จะทำอะไร
    • Automatic Daily - วันนี้ติดอะไร บ้าง
      Note: พวก Automate อันนีใช้ Bot เหมือนได้ยินว่า Slack มี ดังนั้น MatterMost น่าจะมี
    • Reflect every 6 week heartbeat สรุปว่า release นี้มีอะไร
    • Project every 6 week แล้วอนาคตอีก 6 week จะทำอะไรต่อ
    • Announcement แจ้งให้ทั้งองค์กร

Resource พี่ที Share มีเขียน Blog ด้วยครับ ไปตามกันได้ การสื่อสารภายในองค์กรยุคใหม่หลัง Work From Home จะเป็นอย่างไร | by Apipol Sukgler | golfapipol.me | Medium

Misalignment ภัยธรรมชาติของ Team Agility by Pam&Amp

  • เคยเจอเหตุการณ์อะไรไหม ?
    • Dev บั๊กน้อยดี / QA บั๊กเยอะ ดี
    • Mkt ขาย Dev เผา Feature
    • Ops(Infra) ปกป้อง server / Dev อยากทำจะ Deploy
    • A รองาน b แต่ b ทำไม่เสร็จ
    • ทุกคนเอางานมาให้ทีมนี้ทำหมด 55
    • PO อยากให้ Feature ออก แต่ Dev อยากให้เนี้ยบ.. Refactor / Test เพิ่ม
    • Stand-up meeting เป็น status report
  • Misalignment
    • เริ่มต้นจากปัญหา คนคุมล้อ 4 ล้อ ทำอย่างไรให้ไปจุดหมายได้ ตัวอย่างอีกอันที่ผมนึกได้ แปรอักษร บนสแตนเชียร์ ทำอย่างไรให้ได้รูปออกมาตามความหมาย
    • แนวทาง ต้อง planning ทำข้อตกลงร่วมกัน เพราะ Misalignment ตัวที่ขัดขาให้มันช้าลง หรือไม่สำเร็จได้
  • Misalignment ทำไมถึงเป็นภัยธรรมขาติ
    • มันห้ามไม่ได้ ได้แต่ป้องกัน นึกถึง Theory of constraint เลย ปรับและอยู่ร่วมกันมัน
  • Misalignment มีแบบไหนนะ
    • แนวตั้ง - goal หัวหน้า (ต้นน้ำ) - ลูกน้อง (ปลายน้ำ) ไม่ตรงกัน สิ่งที่ควรทำถามว่าทำไปแล้ว มันไปตอบอะไรกับองค์กร ตอบ goal mission อีก key ประนีประนอมให้เข้าใจตรงกัน เช่น UX อยากได้สวยๆ flow สะดวก แต่ Dev
    • แนวนอน แต่ละ team goal ไม่สอดคล้องกัน เช่น Dev และ Ops (infra) หรือ QA กับ DEV
  • Performance Measurement ของแต่ละ Team
    • ทำให้เกิด Misalignment ขัดแย้งกันเอง เช่น Dev บั๊กน้อยดี / QA บั๊กเยอะ ดี
    • พอเอาวิธีการแบบนี้มาทำ Dev ไม่เขียน code เลยจบ 555 หรือกันทุกอย่างจน Flow App มันเพื่อนๆ หรือ QA ไม่แชร์ Test Case เดี๋ยว Dev แก้เท่านั้น
  • มาปรับมุมมองกันไหม เช่น
    • Dev บั๊กน้อยดี / QA บั๊กเยอะ
      ปรับ Goal และ Tester กับ Dev คุยกันแชร์ข้อมูลร่วมกัน และมาดูว่า Test Case อะไรที่ควรเพิ่ม หรือลด
    • Mkt ขาย Dev เผา Feature
      ปรับ Mkt คุยกันถามสุขภาพ Dev ก่อน
    • A รองาน B แต่ B ทำไม่เสร็จ
      ปรับ A คุยกับ B - Align goal ให้ตรงกัน B อาจจะเร่งทำให้ A หรือ อาจจะกลับกัน A มาช่วยงาน B ให้ทัน เพราะมันสำคัญกว่า
    • Standup meeting เป็น Status report
      ปรับ Focus ที่งานตัวเองพอ หรือปรับชื่อเรียก Standup > Daily Planning อาจจะสื่อความได้ดีกว่า
    • สรุป คุยกัน sync ให้เข้าใจตรงกัน และ focus สิ่งที่ทำ
  • Goal vs Solution จุดทำให้ Misalignment ได้ง่ายที่สุด
    • เพราะ Solution มามันเป็นแนวที่ช่วยทำให้ Goal สำเร็จ แต่เราจะยึดติดว่า Solution A ที่เลือกต้องทำให้ได้ Goal นี้ บางทีมัน Work แต่ใช้เวลามากกว่าวิธีอื่น
    • การแก้ No Silver Bullet วิธีการที่ดีในเมื่อก่อน อาจจะไม่ Effective หรือ Work ในตอนนี้ เราเองจะไม่เห็นว่าตัวเองกำลังตกหลุมปัญหา ต้องให้คนอื่นมาช่วย Reflect
  • Key Take Away - เมื่อไหร่ที่เราทะเลาะกัน มีโอกาศเป็นไปได้สูงและที่จะตกหลุม Misalignment ปรับโดย
    1. ปรับ Goal ให้ตรงกัน เพราะไม่มีอะไรที่สำคัญเท่ากันได้นะ
    2. เลือกทาง (Solution) ที่เข้าใกล้มากกว่า

จบงานและ

  • สำหรับ Session ทีชอบที่สุด Theory of Constraint เพิ่มต่อมความเอ๊ะ / Remote First Internal communication ช่วงนี้เจอปัญหาจริงสื่อสาร และคนออกเยอะด้วย มันเลยแบบออกไป chat ไปด้วยจ้า ขอบคุณทีมงานทุกท่านที่จัดงานดีๆนี้ครับ
  • ปีนี้ของกินเยอะ
  • ของแจกก็เยอะ

Blog ของท่านอื่นๆ

Reference

  • Facebook Page AgileThailand มีคน Live ในเพจบาง Session ด้วยนะ เผื่อคนจะมาดูย้อนหลัง กับอีกทีอีกที Network Training Center

Discover more from naiwaen@DebuggingSoft

Subscribe to get the latest posts sent to your email.

Tags

Related Posts