ถอดรหัสความสำเร็จของ Agile Thailand ผ่านเลนส์ของ Flight Levels

งาน Agile Thailand 2022 ที่ผ่านมา พลังงานบวกเต็มงาน หัวข้อแน่นทั้งปริมาณและคุณภาพ ข้าว ขนม กาแฟ เบียร์ และของแจกมากมายมีให้มิได้ขาด ผู้มาร่วมงานเต็มไปด้วยรอยยิ้ม บางคนบอกว่างานนี้เป็นงาน Agile Thailand ที่ดี่ที่สุดตั้งแต่จัดมา 11 ปี!

ถ้าจะมาลองมองย้อนว่าความสำเร็จนี้มาจากไหน ทำไมงานฟรีที่มีแต่ Staff จิตอาสา มาช่วยกันเตรียมหลังเลิกงาน ถึงกลายเป็นงานที่มีแต่คนถามหาตั๋วแม้ว่าจะแจกกันหมดไปกว่า 300 ใบแล้วหลายสัปดาห์ อาจเป็นเพราะคนอัดอั้นกันมานานจากช่วงโควิท อาจเป็นเพราะสถานที่ที่ Bitkub ดึงดูดน่าสนใจ อาจเป็นเพราะแคมเปญโฆษณาอไจล์ในชีวิตจริงที่เอาหน้า Micro Influencer ทั้งหลายมาขึ้นโปรเตอร์สร้างความสนใจไปได้ในวงกว้าง หรืออาจเป็นแค่เพราะความบังเอิญที่หลายๆอย่างลงตัว แต่คงปฏิเสธไม่ได้ว่าความสำเร็จเหล่านี้ส่วนหนึ่งย่อมมาจากทีมงานจัดงาน ที่เราเรียกตัวเองกันว่า Agile66 Staff

Agile66 Staff ผู้อยู่เบื้องหลัง Agile Thailand 2022

ในงานนี้ Lean In เราก็มีโอกาสไปแปะหัวข้อแชร์ด้วย ในหัวข้อที่ชื่อว่า Building Agile Organization with Flight Levels (ดูคลิปย้อนหลังบนเพจได้) ผมเลยคิดว่าเนื้อหาที่เราได้แชร์ไป ก็น่าสามารถนำมาถอดรหัสอธิบายว่า Agile66 Staff มีความเป็น Agile Organization อย่างไร และเราทำงานอย่างไร ถึงจัดงาน scale ระดับนี้ได้ โดยใช้เวลาว่างหลังเลิกงานของ Staff ที่หลักๆมีอยู่ไม่ถึง 10 คน

Agile Organization

ในหัวข้อที่เราพูดนั้น เรานิยาม Agile Organization ว่าไม่ใช่องค์กรที่มีพิธีกรรมทำ Agile แต่เป็นองค์กรที่มีคุณสัมบัติ 4 ข้อคือ

1. Common Goals
2. Fast Feedback Loop
3. Situational Leadership
4. Relentless Improvement

Common Goals

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

Common Goals นี้ ถ้าเป็นเป้าที่สั่งมาจากเบื้องบนโดยไม่ได้สนว่าคนทำคิดอย่างไร อยากทำให้บรรลุเป้าหมายนี้ไหม ก็อาจจะเวิร์คในระยะสั้นเมื่อมีสิ่งล่อใจหรือถูกบังคับ แต่ในระยะยาวมักจะไม่อยู่ยั่งยืน ในหนังสือ Reinventing Organization ของ Frederic Laloux ชวนให้เราคิดว่า

องค์กรที่จะบริหารจัดการตัวเอง (Self Management) ได้นั้น ควรมีเป้าหมายรวมที่ค่อยๆร่วมกันคิด (Evolutionary Purpose) ไม่ใช้เป้าหมายที่ถูกโยนลงมาจากเบื้องบน

Agile66 Staff ที่มาทำงานทุกคนมากันด้วยใจ บ้างก็อยากจะให้คนรู้จัก Agile กันมากขึ้น บ้างก็อยากจะเรียนรู้ Agile มากขึ้น บ้างก็ไม่รู้จะปรับทุกเรื่อง Agile กับใครในที่ทำงาน บ้างก็อยากใช้ความถนัดที่ไม่ได้อยู่ใน Job Description บ้างก็อยากลองทำอะไรใหม่ๆที่ไม่เคยลองทำมาก่อน บ้างก็อยากมาหามิตรภาพ ทุกคนอาจมีเป้าประสงค์ที่ไม่ได้เหมือนกันสักทีเดียว แต่เขาเหล่านั้นก็มีเป้าหมายร่วมกันว่าการได้มาเป็นจิตอาสา Agile66 Staff ได้ตอบโจทย์อะไรบางอย่างของเขา

Fast Feedback Loop

องค์กรที่มี Agility หรือความคล่องตัวนั้น แน่นอนว่าต้องมีการปรับตัวตอบสนองอย่างรวดเร็วกับการเปลี่ยนแปลง หลายคนอาจจะเคยเจอว่าเราก็ทำงานเป็น Sprint นะ เราน่าจะมี Fast Feedback Loop แต่เอาเข้าจริงๆเราก็ยังดันทุรังทำตามแผนใหญ่ที่ใครสักคนกำหนดไว้ไปเรื่องๆ ก็ไม่รู้เหมือนกันว่าจะทำ Sprint กันไปทำไม

การจะทำให้เกิด Fast Feedback Loop จริงๆจึงเป็นเรื่องของ Mindset มากกว่าท่วงท่า

ในช่วงปีแรกๆของการทำงานจัดสัมมนาของ Agile66 Staff เราพยายามทำงานเป็น Sprint แต่พบว่าเป็นไปไม่ได้เลย เหตุผลหลักๆคือเนื่องจากเราเป็นทีมงาน part-time ที่เอาเวลาว่างซึ่งก็ไม่แน่ไม่นอน มาช่วยกันทำ การจะหาเวลานัดให้ว่างตรงกันเป็นเรื่องที่ยากมากๆ ช่วงปีหลังๆแม้จะพยายามแค่ใครว่างมาก็เจอกันทุกสองสัปดาห์ หรือทุกสัปดาห์ช่วงใกล้ๆงาน ก็ยังกระท่อนกระแท่น เพราะเราแทบไม่เคยว่างตรงกัน

ปีนี้แทนที่จะดันทุรังไปกับ Synchronous Communication ซึ่งต้องการให้ทุกคนมาพร้อมหน้ากัน เราเลยได้โอกาสลองใช้ Asynchronous Communication คือมีอะไรก็คุยกันใน Line Group นั่นแหละ แต่ว่ามีตัวช่วยคือมี Visualization เช่น Google Spreadsheet และ Miro และถ้าอยากจะนัด Zoom คุยกันเพราะรู้สึกว่าเรื่องมันเยอะก็นัดคุยกันได้เลย

Space #6 ที่ย้ายลงมาหลังจาก Feedback ว่าข้างบนร้อนมาก

ในวันงานปีนี้ช่วงเช้า เราพบว่าห้อง #6 ร้อนมาก เพราะแดดส่องแล้วเราไปเปิดประตูกะให้ลมเข้า ลมก็เข้ามาจริงๆแต่เป็นลมร้อน เลยไปกันใหญ่ เราเลยตัดสินใจย้ายห้องลงมาพื้นที่ชั้นล่าง ซึ่งเพิ่งรู้ก่อนวันงานเพียง 1 วัน ว่าตรงนี้ก็ใช้ได้ แล้วก็ช่วยกันย้ายเก้าอี้จากห้อง #1 โถงกลางที่ไม่ได้ใช้เข้าแล้วเพราะนั่งแสตนด์ได้ เข้ามาจัดพื่นที่แทน ก่อนหน้างานและในวันงานยังมีเรื่องที่ไม่ได้เป็นไปตามแผนที่วางไว้อีกมากมาย เราก็ปรับกันไปตามสิ่งที่เกิดขึ้นจริง

Situational Leadership

ไม่มีใครจะรู้ดีไปหมดทุกเรื่อง แม้กระทั่งหัวหน้าหรือผู้นำ Agile Organization จึงไม่มุ่งเน้นที่จะมีหัวหน้าที่มาจากการแต่งตั้งหรือเป็นโดยตำแหน่ง แต่จะส่งเสริมให้เกิดผู้นำที่ลุกขึ้นมานำ ในสถานการณ์ที่เหมาะสม

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

ปีนี้น้องๆโทรมาหาผมครั้งเดียวเพื่อมาถามว่า “พี่ปอมเรื่องนี้เขาจะเก็บตังค์เพิ่มนะ พี่จ่ายได้ใช่ไหม” นอกนั้นเขาก็ช่วยกันตัดสินใจได้ บางคนถนัดจัดการก็ลุกขึ้นมานำการจัดการเป็นแม่งาน บางคนถนัดสายจิตวิทยามวลชนก็ลุกขึ้นมาจับไมค์เอ็นเตอร์เทน บงคนถนัดสายจิตบำบัดก็ลุกขึ้นมาช่วย Heal โดยไม่ได้มีใครมาแต่งตั้ง

Relentless Improvement

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

งานสัมมนาทั้ง Agile Thailand และ Agile Tour Bangkok ที่จัดโดย Agile66 Staff แม้ว่าเราจะจัดกันมาเป็นสิบปีและมีแบบแผนที่ค่อนข้างลงตัวแล้ว แต่เราก็ยังมองการจัดงานทุกครั้งเป็นโอกาสที่จะได้ลองอะไรใหม่ๆ เพื่อปรับปรุงให้งานได้ผล คนทำงานสนุก ยิ่งๆขึ้นไปอยู่เสมอ และการปรัปปรุงที่ว่านี้ ไม่ต้องรอ Retrospective ไม่ต้องรองานหน้า ใครอยากลองอยากทำอะไร ก็ทำได้เลย

Flight Levels

เล่ามาตั้งยืดยาว ยังไม่ได้บอกอะไรเกี่ยวกับ Flight Levels เลย มาทบทวนกันสักหน่อยว่า Flight Levels คืออะไร

Flight Levels คือหลักคิด (Thinking Model) ที่ช่วยให้องค์กร “ออกแบบ” โครงสร้างและกระบวนการทำงานในองค์กร เพื่อให้เกิดความคล่องตัวทางธุรกิจ (Business Agility) ได้จริง โดยผู้ให้กำเนิดหลักคิดนี้คือ Dr. Klaus Leopold

รูปจาก Flight Levels Workshop

Flight Levels แบ่งโหมดการทำงารในองค์กรออกเป็น 3 ระดับคือ

• L1 ระดับ Team ที่ทำงาน Operation
• L2 ระดับ Flow ที่มี Coordination ระหว่าง Team
• L3 ระดับ Goal ที่เป็นการวาง Strategy

ปัญหาในองค์กรส่วนใหญ่ แม้ว่าจะทำ Agile แล้ว ก็คือทีมมักจะไม่ประสานกัน ต่างทีมก็ต่างทำ ไม่เกิด End-To-End Flow หนำซ้ำ Goal ที่วางไว้ก็ปรับเปลี่ยนไม่ทันกับสถานการณ์หน้างานที่เกิดขึ้นกับทีม

Flight Levels จะเป็นหลักคิดที่ใช้ในการออกแบบว่าเราจะสร้างระบบการทำงาน (Work System) ขององค์กรอย่างไรให้เกิด Agility ทั้งใน “แนวนอน” ระหว่างทีมและใน “แนวตั้ง” คือเชื่อมประสานเป้าหมายขององค์กรกับทีม

จาก Org Structure สู่ Work Structure (วาดโดยกร)

ในองค์กรทั่วๆไป เรามักจะมีโครงสร้าง Org Chart คล้ายๆรูปด้านบนฝั่งซ้าย แต่ในการทำงานจริง เรามักจะไม่ได้อยู่แต่ในแผนกใน Silo ของเรา งานมักจะเริ่มต้นจากใครสักคนที่สักแผนกหนึ่ง เมื่อทำเสร็จแล้วก็ต้องส่งต่อกันเป็นทอดๆ กว่าจะครบทั้ง Value Stream ไปถึงมือลูกค้า

Flow ของการทำงานที่ต้องส่งต่อกันเป็นทอดๆนี้มีอยู่แล้วในองค์กร แม้ว่าเราจะทำ Agile หรือไม่ก็ตาม บางทีเราเรียกมันว่า Dependency เพราะเรามองจากในมุมของเราว่าเรารอเขาอยู่ แต่ผมอยากจะชวนถอยมามองภาพใหญ่ มองให้เป็น Flow การไหลของงาน ซึ่งในองค์กรนั้นแน่นอนว่าจะมีหลาย Flow ทับซ้อนกันไปหมด

ถ้าเปรียบ Flow ของงานที่ไหลนี้เป็นดั่งถนน บางช่วงก็อาจจะเป็นถนนลูกรัง บางช่วงลาดยาง บางช่วงก็เป็นถนนแปดเลนซุปเปอร์ไฮเวย์ บางช่วงอาจจะทางขาดต้องสร้างสะพานข้าม บางช่วงอาจเป็นทางลับที่น้อยคนนักจะรู้ว่ามี

การออกแบบ Flight Levels ในองค์กรคือการทำความเข้าใจ Flow เส้นทางการไหลของงานเหล่านี้แล้วเปลี่ยนมันให้กลายเป็นทางด่วน

ถ้ากลับไปมองภาพด้านบนอีกครั้งแล้วสังเกตสีของลูกศรแต่ละ Flow ทางด้านซ้ายจะเห็นว่าตรงกับวงกลมที่อยู่ใน L2 ทางด้านขวา ภาพนี้ต้องการจะสื่อความว่าเมื่อเราเลือก Flow ที่ต้องการแล้ว เราจะนำมันมาสร้าง Flight Level 2 เพื่อให้เกิด Coordination ระหว่างทีมที่เกี่ยวข้อง ซึ่ง Flight Levels แนะนำให้เราสร้าง Coordination ให้ End-to-End มากที่สุดเท่าที่จะเป็นไปได้ คือตั้งแต่ต้นน้ำไปยังปลายน้ำ เพื่อให้ความคล่องตัวเกิดขึ้นตลอดทั้ง Flow

แต่ละ Node ในรูปด้านบนนี้ ภาษาทางการของ Flight Levels เรียกมันว่า Work System ซึ่งจะประกอบไปด้วย (1) Visualization และ (2) Regular Interaction ซึ่งถ้าเราทำ Scrum เราก็อาจจะคุ้นชินกับการใช้ Visualization เช่น JIRA หรือ Physical Board และมี Regular Interaction คือ Scrum Events ทั้งหลาย

Flight Level 2 — Flow

ในงาน Agile Thailand 2022 ปีนี้เราได้สร้าง Work System ขึ้นมาหลายจุด โดย Work System ใน Level 2 ที่เรามีก็เช่น Agile66 x Bitkub สำหรับประสานงานกันเรื่องสถานที่ และ Sponsor Support สำหรับประสานงานกันเรื่องสปอนเซอร์(ซึ่งปีนี้ประสานกันสนุกมากเพราะมีถึง 15 เจ้า!)

Visualization ที่ดูจะเวิร์คมากๆในคราวนี้ก็คือ Google Spreadsheet ที่เราเอามาทำรายการของงานของ PR Campaign, รายการของตั๋ว และรายการของสปอนเซอร์ แต่บาง System ก็คุยกันเฉยๆโดยไม่ได้มี Visualization อะไรช่วย ซึ่งเครื่องมือที่เราใช้ในการคุยก็คือ Line Group ธรรมดานี่แหละ เพราะว่าส่วนใหญ่ทุกคนอยู่บน Line กันอยู่แล้ว จะมียกเว้นก็คือทีมสปอนเซอร์ปีนี้ ที่ส่วนใหญ่อยู่บน Discord เราก็เลยไปใช้ Discord

ส่วนใหญ่การคุยกันจะไม่ได้มีการนัดประชุมเลย

งานทั้งงานแทบจะจัดด้วยการสื่อสารแบบ Asynchronous หรือเรียกง่ายๆว่าแชททิ้งไว้ ใครว่างก็ค่อยมาอ่าน

ตามจังหวะ Regular Interaction ของตัวเอง บางคนอาจจะตื่นมาเช็คทุกเช้า บางคนเช็คตลอดเวลา ก็แล้วแต่สะดวกเลย

ที่น่าสนใจคือวงของ Sponsor Support ซึ่งเราเชิญตัวแทน Sponsor เข้ามาในวงเลย แล้วก็มีตัวแทน Agile66 Staff ที่ดูแลเข้าไปบางคน แทนที่เราจะแยกคุยสปอนเซอร์แต่ละรายทีละราย เราทดลองเอาสปอนเซอร์มาอยู่ใน Line Group เดียวกัน และกาง Google Spreadsheet ให้เห็นกันหมดว่า ใครช่วยเรื่องอะไรและจะนัดส่งของกันอย่างไร ปรากฎว่าเจ้าที่ช่วยกาแฟต้องการหาที่สั่งน้ำแข็ง เจ้าที่ช่วยเบียร์เลยขอฝากสั่งด้วยเพราะว่าต้องการน้ำแข็งเหมือนกัน

เรื่องนี้ฟังดูอาจเป็นเรื่องเล็กน้อย แต่นี่คือประโยชน์หลักๆของการสร้าง Flight Level 2 ให้คนที่เกี่ยวข้องมาประสานกัน และช่วยกันติดสินใจ โดยไม่ต้องรออำนาจสั่งการจากหัวหน้า ตัวแทน หรือ Project Manager

🍺 ประโยชน์ของ Flight Level 2 🍺

Portfolio

แน่นอนว่าบนทางด่วนรถก็ติดได้ถ้ารถขึ้นไปวิ่งบนทางด่วนกันหมด ดังนั้นเราก็ต้องมีศูนย์จราจรที่คอยอำนวยการด้วยว่า Flow ที่วิ่งอยู่ติดขัดตรงไหนไหม จังหวะนี้อาจต้องปิดถนนให้อีกทางไปก่อน ซึ่ง Flight Levels เรียก Coordination of Coordination นี้ว่า Portfolio

ในการทำงานจิตอาสานั้น เรากะเกณฑ์ไม่ได้เลยว่า งานนี้ วันนี้ จะมีใครมาช่วยมากน้อยแค่ไหน เพราะแต่ละคนว่างไม่ตรงกัน Staff บางคนมาทุกปี Staff บางคนหายไป 5 ปีแล้วก็กลับมาใหม่ ใครที่เคยมาช่วยงานกันแล้วก็ยังทักกันอยู่ ไม่ว่าจะมีโอกาสมาช่วยกันแค่ไหน เราก็จะไปคุยกันอยู่ในห้องใหญ่ที่เราเรียกว่า Agile66 Staff Family

ช่วงสองสามปีหลัง ก็เริ่มมี Staff บางส่วนที่กลายเป็นแกนหลักของการจัดงาน ด้วยธรรมะจัดสรร ทำงานด้วยกันแล้วถูกใจกัน ก็จะเป็นเสมือนศูนย์จราจรที่คอยอำนวยความสะดวกของ Flow ที่เราเรียกว่า Portfolio และก็เป็นคนลงมือทำงานในบาง Flow ด้วย

Flight Level 3 — Goal

ในส่วนของ Flight Level 3 ซึ่งเป็นโหมดของการปรับ Strategy ให้เป็นไปตาม Goal ก็ยังเป็นส่วนที่แกนหลักเป็นคนช่วยกันทำ พอลองมานึกย้อนถอดรหัสดู ก็พบว่าเรา Agile Thailand ของเรามี Goal คือ สร้างโอกาสให้คนมาแลกเปลี่ยนประสบการณ์อไจล์กัน โดย Strategy ที่ใช้คือ

1. จัดงานให้ผู้ร่วมงานด้วย Unconference & Open Space Technology — ไม่มี Agenda ล่วงหน้า คนที่มาคือคนที่ใช่
2. ร่วมมือกับสปอนเซอร์แบบ งานบุญ — ไม่รับเงิน เอาของขนมาช่วยกัน
3. ทีมงาน Staff ทำงานแบบ Self Management-บริหารจัดการตัวเอง ทำในสิ่งที่อยากทำ

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

อดีต Scrum Master / IT Manager ผันตัวมาเป็นศิลปิน

Flight Level 1 — Team

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

Flight Level จึงไม่ได้กล่าวถึงว่าที่ Level 1 นั้นทีม(หรือไม่ได้เป็นทีม)จะทำงานอย่างไร ซึ่งก็สอดคล้องกับประโยคเด็ดที่ Klaus Leopold ผู้คิดค้น Flight Levels เอามาขยายความชื่อหนังสือ rethinking Agile ของเขาว่า Why Agile Teams Have Nothing to Do with Business Agility

ส่งท้าย

แม้ว่าเรื่องที่เล่ามาในบทความนี้ จะเป็นเพียงเรื่องราวของคนไม่กี่คนที่มีจิตอาสามาร่วมกันจัดงานสัมมนา แต่เชื่อหรือไม่ว่า จากประสบการณ์การที่ Lean In ได้เข้าไปช่วยองค์กรหลากหลายที่เริ่มนำ Agile เข้าไปใช้ โดยเฉพาะองค์กรที่ไม่ได้มี Software Development เป็นองค์ประกอบหลักของธุรกิจ ปัญหาและความท้าทายที่เจอในองค์กรก็แทบไม่ต่างกับที่ Agile66 Staff ได้ประสบพบเจอเลย

ทีมส่วนใหญ่ที่ถูกจับมาทำ Agile Project มักจะมีงานประจำต้องทำขนาดกันไปด้วยเสมอ ไม่ได้มีโอกาสมานั่งด้วยกันเป็นทีมประจำที่อุทิศเวลามาทำ Agile Project อย่างเดียว หนำซ้ำตอนนี้ก็เป็น Hybridge บางคนอยู่ที่ทำงานบางคนอยู่บ้าน อย่างที่ผมเคยบันทึกไว้ในบทความก่อนหน้านี้เรื่อง บันทึกการช่วยทำ Non-IT Agile Part-Time Project แบบทุกคน WFH

เป็นไปได้ไหมว่า บทเรียนที่เราถอดรหัสจากการนำ Flight Levels มาใช้ในการจัด Agile Thailand ก็อาจจะมีประโยชน์กับการทำ Agile ในองค์กรก็เป็นไปได้ 😉