เล่าเรื่อง Business Agility จาก class Flight Levels System Architecture

รูปจาก blog ของ Klaus Leopold — Flight Levels: The Organizational Improvement Levels

เมื่อวันที่ 5–6 มีนาคม 2020 ที่ผ่านมา ผมมีโอกาสไปเรียนคลาส Flight Levels Systems Architecture ที่พี่ปอม Kulawat Pom Wongsaroj จัด สอนโดย Klaus Leopold จาก Leanability ผมพบว่ามีเรื่องน่าสนใจหลายอย่าง เลยอยากเอามาเล่าให้ฟังครับ (ขออภัยครับ ดองบทความไว้นานจนลืม 🙏)

Spoil Alert! ผมหยิบเนื้อหาบางส่วนมาจากหนังสือของ Klaus มาผสมด้วยนะครับ สนใจเพิ่มเติมก็ลองหามาอ่านดู เล่มนี้ครับ Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility (Amazon :- https://tinyurl.com/tkxla77)

Flight Levels

Flight Levels เป็นเทคนิคที่มีแนวคิดพื้นฐานมาจาก Kanban เพื่อทำ Business Improvement ให้เกิดความคล่องตัวในการบริหารงาน (Business Agility) โดยที่ Flight Levels เป็น Thinking Model ที่ใช้อธิบาย coordination กันระหว่างชั้นของการทำงาน ตั้งแต่ C-Level ลงมาจนถึงระดับทีม และอธิบาย coordination ระหว่างทีมต่างๆ ที่ทำงานร่วมกัน เพื่อให้เห็น value creation chain ตั้งแต่ระดับ strategy หรือ upstream ไปจนถึง outcome measurement ที่ downstream เลย มันเลยเป็นเครื่องมือสำหรับองค์กรเพื่อใช้ทำ Business Agility ไม่ใช่เครื่องมือสำหรับการทำ Agile team

Agile Team vs. Agile Organization

หลายปีที่ผ่านมา องค์กรขนาดใหญ่พยายามที่จะเอาแนวคิดของ Agile ไปปรับใช้ในหลายๆ ส่วนนอกเหนือไปจากฝ่าย IT เพื่อให้เกิดความคล่องตัว เพราะแนวคิดของ Agile มันกลางๆ อ่านดูแล้วก็เหมือนกับไม่ได้เจาะจงแค่การทำซอฟท์แวร์ บางองค์กรถึงกับปรับโครงสร้างแผนกต่างๆ เลย เช่น เปลี่ยนโครงสร้างเป็น Spotify Model เป็นต้น แต่พอทำจริงก็พบว่ามันมีปัญหามากกว่าที่คิด บางองค์กรถึงกับบอกว่า “Agile ไม่ work”, “Agile ไม่เหมาะกับเรา” หรือ “มันเป็นได้แค่ทฤษฎีเท่านั้นแหละ” คำถามคือ ทำไมองค์กรขนาดใหญ่บางแห่งทำแล้วประสบความสำเร็จ แต่ที่อื่นๆ อีกมากมายกลับไม่เป็นอย่างนั้น

ก่อนที่จะไปดู Flight Levels เรากลับมาดูคำ 2 คำนี้กันก่อนครับ คือ “Agile Team” กับ “Agile Organization” ซึ่ง 2 เรื่องนี้ไม่เหมือนกัน Klaus พูดเสมอว่า Agile Team ไม่ได้เกี่ยวอะไรเลยกับการจะทำให้ธุรกิจเกิดความคล่องตัว (สังเกตุได้จากหน้าปกหนังสือ Rethink Agile) เรามาดูครับว่ามันยังไง

ย้อนกลับไปที่ Agile Team ก่อน คนส่วนใหญ่มักจะคุ้นเคยกับวิธีการทำงานแบบ Scrum ซึ่ง Scrum เข้ามาแก้ปัญหาการทำงานที่ไม่คล่องตัวจากการที่สมาชิกในทีมแยกกันทำงานคนละแผนกแต่ต้องทำ product หรือ project เดียวกัน เช่น System Analyst ก็อยู่แผนกนึง, Developer และ Tester ก็อยู่คนละแผนก แนวทางของ Scrum ก็เลยแก้ปัญหานี้ด้วยการ bypass โครงสร้างองค์กร ด้วยการสร้างทีมที่มีสมาชิกที่สามารถส่งมอบงานได้เองโดยไม่ต้องรอคนนอกทีม เกิดเป็น cross-function team ขึ้นมาเพื่อลด dependency ให้มากที่สุด เมื่อ dependency หายไป มันก็คล่องตัวไม่ต้องรอกัน งานก็เลยออกมาเร็วเมื่อเทียบกับเมื่อก่อนที่ต้องรอกันไปรอกันมา นี่คือ Agile Team

เมื่อเห็นว่าการสร้าง cross-functional team มันทำให้งานเสร็จเร็ว ก็เลยมีแนวคิดที่จะเอารูปแบบการทำงานแบบนี้มาใช้กับฝ่ายอื่นๆ บ้างเพราะเชื่อว่าการปรับโครงสร้างเป็นแบบนี้แล้วจะทำให้งานออกมาเร็ว และองค์กรก็จะกลายเป็น Agile Organization … ปัญหาก็คือ มันไม่ได้ตรงไปตรงมาแบบนั้น

Case Study

ในหนังสือยกตัวอย่างว่า องค์กรหนึ่งต้องการ transform ให้องค์กรเป็น Agile Organization เพื่อให้การพัฒนา product มี time-to-market สั้นที่สุด ก็เลยจ้าง external Agile Coach เข้ามาเพื่อช่วยปรับโครงสร้างองค์กรให้เป็น Agile สิ่งที่เกิดขึ้นก็คือ

• มี class อบรม Introduction to Agile ทั้งองค์กร 1 วัน
• เปลี่ยนโครงสร้างทีม product ให้เป็น Agile Structure เช่น Tribe/Squad
• แต่ละทีมมี Product Owner ของตัวเอง
• มี Internal Agile Coach โดยเปลี่ยนคนจากตำแหน่ง Project Manager หรือ Team Lead โดย external coach จะคอยสอนว่าจะต้องทำอะไรบ้าง
• กำหนด Agile Ceremonyให้ทุกทีม โดยแบ่งรอบการทำงานเป็น Sprint รอบละ 2 สัปดาห์ เริ่ม Sprint ด้วยการ planning, มี Standup Meeting ทุกเช้า จบ Sprint ด้วยการ Review และ Retrospective ทุกๆ Sprint
• ขั้นตอนทั้งหมด management ให้การสนับสนุนเต็มที่ โดยปล่อยให้ทีมและ PO ทำงานได้อย่างอิสระตามที่ external coach แนะนำ

หลังจากที่ผ่านการ transform โครงสร้างและรูปแบบการทำงานแล้ว ทุกทีมก็จะมี board เพื่อคอย sync งานของทีม และทำ activity ตามที่ตกลงกันทุกทีม เมื่อผ่านไประยะเวลาหนึ่ง external coach ก็จบงาน Agile Transformation และปิดจ๊อบไป ทุกอย่างก็ดูดีเหมือนจะไม่มีปัญหาอะไร

เมื่อเวลาผ่านไประยะหนึ่ง management พบว่า แทนที่ทีมต่างๆ จะทำงานได้เร็วขึ้น แต่กลับกลายเป็นว่าทำงานได้ช้าลง time-to-market ที่อยากให้เร็วก็ไม่เร็วอย่างที่คิดไว้ ในขณะที่การทำงานร่วมกันระหว่าง Agile Team ก็ยากขึ้นเพราะ PO แต่ละทีมก็มี Priority เป็นของตัวเอง ในขณะที่ visibility ที่มันควรจะชัดขึ้นเพราะทุกทีม transparent งานตัวเองหมดแล้วกลับ track ยากกว่าเดิม มันเกิดอะไรขึ้น

Sub-optimization

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

สมมติว่าขั้นตอนเหล่านี้คือขั้นตอนการผลิดสินค้า แม้ว่าจุดที่ 4 จะทำงานได้เร็วมาก แต่จุดอื่นๆ ไม่ได้เร็วตาม โดยเฉพาะจุดที่ 2 ที่ช้าที่สุด เพราะฉะนั้นสุดท้ายแล้ว ความเร็วรวมของการผลิตก็ยังช้าอยู่ดี

การทำ Agile Team แค่ทีมนึง หรือไปทำ Agile process ในฝ่าย IT ฝ่ายเดียว อาจจะช่วยให้ได้ output เร็วขึ้น แต่ถ้าคุณต้องการให้ทั้งองค์กรคล่องตัว คุณต้อง optimize ทั้งองค์กร ไม่ใช่แค่ฝ่าย IT ซึ่งบ่อยครั้งที่องค์กรขนาดใหญ่เปลี่ยนการทำงานของฝ่าย IT เพื่อให้ได้ output เร็วชึ้น แต่การทำงานของฝ่ายอื่นที่เกี่ยวข้องก็ยังเหมือนเดิม

เพราะฉะนั้น การทำให้องค์กรคล่องตัว (สร้าง Business Agility) จึงไม่ใช่การสร้างแค่ Agile Team หรือที่ Klaus สรุปไว้ว่า Agile Team ≠Business Agility

Flight Levels Architecture

ปัญหาหนึ่งของการทำ Agile Transformation ก็คือ บ่อยครั้งที่ management ยังไม่ทันที่จะเข้าใจปัญหาที่แท้จริงเลย ก็ทำการเปลี่ยนโครงสร้างแล้ว ซึ่งปัญหาที่เห็นอาจจะเป็นแค่ผลที่ตามมา (consequence) ที่มี root cause มาจากปัญหาอื่นก็ได้ แนวทางของ Flight Levels จะเหมือน Kanban ที่พยายาม Visualize Flow การทำงานก่อนเพื่อให้เห็นว่าปัญหาที่แท้จริงมันอยู่ตรงไหน แล้วค่อยๆ measure + improve ไปทีละจุด

Flight Levels จะมีระดับของ board อยู่ 3 ระดับ ตามรูป

Level 1 — Operational Level: ที่ level นี้ จะเป็นการ visualize การทำงานของแต่ละทีมเพื่อให้เห็น flow และ WIP (Work-In-Progress) ของแต่ทีมจะใช้ process อะไรก็ได้ ไม่ว่า Scrum, Kanban, แล้วแต่ที่ทีมคิดว่าเหมาะสม

Level 2 — Cooperation Level: ที่ LV2 จะเป็น level ที่ให้หัวหน้าหรือตัวแทนของแต่ละทีมมาทำงานร่วมกัน เพื่อให้เห็น flow ของการส่งของระหว่างทีมและเกิดการวางแผนและกำหนด priority ร่วมกัน

Level 3 — Strategic Portfolio Management: ที่ level นี้จะสำหรับ high-level management ระหว่างฝ่ายต่างๆ วางแผนและประสานงานกันเพื่อให้งาน flow ทั้งองค์กร

เมื่อ map ภาพทั้ง 3 level เข้าด้วยกัน จะช่วยให้ทั้งองค์กรเห็น flow และความสัมพันธ์ในแต่ละระดับ ตั้งแต่ระดับบริหารไปจนถึงระดับปฏิบัติการ ถ้าจุดไหนที่เป็นอุปสรรค ไม่ว่าจะเป็นเรื่อง capacity หรือระเบียบการทำงาน ก็จะเกิดการพูดคุยและแก้ปัญหาในทุกระดับไม่ใช่แค่จากบนลงล่าง แต่จะสะท้อนการทำงานจากระดับล่างขึ้นบนและระหว่างทีมต่างๆ ด้วย

From Strategy Level to Implementation Level

ประโยชน์ที่ได้จากการ map flow ตั้งแต่ level 3 มีหลายอย่างเลยครับ คือ

1. อธิบายได้ว่า งานที่ทำอยู่ เกี่ยวข้องกับกลยุทธขององค์ยังไง — บ่อยครั้งเมื่อผมเข้าไปในองค์กรใหญ่ๆ ผมพบว่าคนทำงานบอกไม่ได้ว่างานที่ทำอยู่มันเกี่ยวกับองค์กรยังไง มันแตกหน่อออกมาจากกลยุทธข้อไหน เมื่อใช้ Flight Levels map flow ตั้งแต่ระดับกลยุทธขององค์กรลงมา คนทำงานจะเห็นภาพชัดเจนว่างานที่ตัวเองกำลังทำ จะมีผลกับลูกค้าและองค์กรยังไงในทุก level
2. ช่วย limit WIP — ใน class Flight Levels ไม่ได้พูดถึง WIP มากนัก แต่ผมพบว่า เมื่อเรา visualize งานของแต่ละทีมออกมา เราจะเห็นว่าแต่ละทีมทำอะไรอยู่ มันช่วยอธิบายได้ชัดเจนว่าทำไมงานที่ management อยากได้ มันไม่เสร็จเสียที (ซึ่งงานที่อยู่ในมือของทีมก็มาจาก management นั่นแหละที่สั่งให้ทำ) เมื่อผูกมันเข้ากับ strategy ขององค์กร เราจะพบว่ามีงานหลายอย่างเลยที่มันไม่ได้สอดคล้องกับกลยุทธขององค์กร ถึงตอนนี้ management จะสามารถตัดสินใจได้ดีขึ้นว่า งานไหนที่ควรให้ทีมทำหรือไม่ควรให้ทำ
3. Prioritization — เมื่อต้องทำงานกับหลายๆ แผนก เราจะพบว่าความสำคัญของงานแต่ละแผนกไม่เหมือนกัน (และแน่นอนว่า งานแผนกตัวเองสำคัญกว่างานของแผนกอื่นเสมอ) เมื่อความสำคัญของงานของแต่ละแผนกไม่สอดคล้องกัน มันก็ทำให้เกิดการรอและล่าช้า เมื่อ map ด้วย Flight Levels ทั้ง 3 level มันจะช่วยให้ management สามารถกำหนด priority ของแต่ละทีมได้ด้วยหลักการเดียวกัน คือลำดับความสำคัญของงานตาม strategic ขององค์กร แต่ละทีมก็จะทำงานอย่างสอดประสานกันได้เป็นจังหวะเดียวกัน
4. Measurement — ใน class Agile หรือ UX พูดเสมอว่า การที่เราทำ product ออกมา 1 ตัว โดยเฉพาะ software ที่จริงแล้วลูกค้าไม่ได้อยากได้ output หรือ feature ที่เราพยายามใส่ลงไปใน software แต่เค้าอยากได้ outcome หรือ value ที่ product ตัวนั้นส่งมอบให้เค้า เช่น เค้าทำธุรกรรมสะดวกขึ้น เค้าไม่ต้องไปเข้าคิวก็ทำเองได้ เค้าอยากลดเวลาในการรอจากกระบวนการที่เยิ่นเย้อ เค้าอยากมีชีวิตที่ดีขึ้นจากสินค้าและบริการของเรา เพราะฉะนั้น feature หรือ output เป็นเรื่องรอง แต่ outcome หรือ value ที่ product ส่งมอบให้ลูกค้าสำคัญกว่า แต่บ่อยครั้งที่ management (โดยเฉพาะ middle-level management) มักจะพยายามให้ทีมทำ feature ออกมาเยอะๆ เพราะมันวัดยากว่า outcome ที่ต้องได้มันคืออะไร ซึ่ง Flight Levels จะช่วย map output และ outcome ตั้งแต่ strategic level จนถึง operational level เลย ซึ่งช่วยให้ทุกส่วนขององค์กรกำหนดการวัดผลได้อย่างสอดคล้อง ถึงตอนนี้ไม่ว่าคุณจะใช้ KPI หรือ OKR มันก็ make sense ละ

Flight Levels is not a Process

Flight Levels ก็เหมือน Agile Framework หลายๆ ตัวในโลกของ Agile ที่ตัวมันไม่ได้บอกว่าต้องทำยังไงชัดเจน เหมือนกับตำราอาหารที่ไม่ได้การันตีนะว่าทำตามแล้วจะอร่อย มันต้องปรับปรุงไปตลอดทาง เพราะฉะนั้นสิ่งที่ต้องจำไว้ก็คือ Flight Levels เหมือน Kanban เลย คือต้องมี process เดิมอยู่แล้ว จากนั้นก็​ visualize ขึ้นมาให้เห็นเป็นภาพเดียวกันก่อน แล้วค่อยๆ improve กระบวนการและวัดผลไปเรื่อยๆ เพราะฉะนั้นถ้าใครคาดหวังว่า ถ้าจ้าง consult มาทำ Flight Levels แล้วปัญหาจะหายไป คำตอบคือ ไม่ครับ ที่สำคัญคือ management ต้องทำเองด้วย เพราะคนที่กำหนดทิศทางขององค์กรก็คือ management และคนที่แก้ปัญหาเรื่อง cooperation ให้กับองค์กรใน level ที่ต่ำกว่า ก็คือ management ที่ level สูงกว่าครับ

My Opinions

จากตรงนี้ เป็นความเห็นคิดเห็นของผมเองนะครับ อ่านแล้วเห็นไม่ตรงกันก็ไม่ feedback ได้ครับ

1. Where to Start? — ใน class Klaus บอกว่าส่วนใหญ่คนที่เอาไปใช้มักจะเริ่มที่ level 2 เพราะมักจะเจอปัญหาจากการทำงานข้ามแผนกนี่แหละ (จากที่เคยทำก็ทำที่ LV2 เพราะขึ้นไม่ถึงผู้บริหารระดับ LV3) แต่ Klaus ก็แนะนำว่า ถ้าเป็นไปได้ ไปขอ support จาก level สูงที่สุดที่เราไปหาได้ เพราะต่อให้เริ่มที่ LV2 ก็ต้องอาศัยการสนับสนุนของ high-level management อยู่ดี (ส่วนใหญ่ middle-level management ในองค์กรใหญ่จะไม่ทำอะไรข้าม area ของตัวเอง ด้วยหลายๆเหตุผล)
2. มันทำงานร่วมกับ Framework หลายๆ ตัวได้นะ — เมื่อ Flight Levels มัน map ซะทุกระดับชั้นขนาดนี้ ผมมองว่าถ้าเราจะ Scale Agile Team ด้วย LeSS หรือ Spotify Model มันก็ทำได้นะ ผมมองว่ามันไม่ได้ขัดกัน แค่เราเลือกใช้ให้เหมาะกับปัญหาเท่านั้นเอง
3. Management Support — อันนี้เป็นความเห็นด้วยของผมเองจากที่ Klaus แนะนำใน class คือ ไม่ว่า Flight Levels จะเกิดที่ level ไหน management ที่ level นั้น (และ level ที่สูงกว่า) จะต้อง “ลงมือทำด้วยตัวเองด้วย” มากกว่าแค่ support แล้วปล่อยให้ทำกันเอง เพราะเมื่อถึงจุดที่เกิด conflict มันต้องมีคนเคาะว่าไปทางไหน ถ้าไม่มีคนที่ level สูงกว่า ก็มักจะตกลงกันเองไม่ได้หรือไม่ก็ปล่อยให้ปัญหาอยู่ที่เดิม มันก็เกิดความล่าช้าไม่คลฃ่องตัวเหมือนเดิม
4. Make sense — ถ้าย้อนกลับไปดูวิธีการทำ Agile Transformation ของหลายๆ แห่งเราจะพบว่าส่วนใหญ่แล้วจะเริ่มจากการเปลี่ยน structure เช่น เปลี่ยนแผนกต่างๆ เป็นแบบ Spotify และกำหนด Agile Ceremony (ผมมองว่าได้รับอิทธิพลมาจาก Scrum) แต่ผมกลับรู้สึกว่าแนวทางของ Flight Levels มัน makesense ในการ transform มากกว่า เมื่อลองเอาแนวทางของ Flight Levels มาล้อกับ Agile Manifesto อย่างในข้อแรกที่บอกว่า Individual & Interaction OVER Process & Tools ผมก็เห็นว่า Flight Levels แค่ visualize flow ของงานขึ้นมาก่อน เพื่อให้เห็นว่า individual นั้น interaction กันยังไง มีปัญหายังไง แล้วค่อยแก้ปัญหามากกว่าการเอา process ไปครอบตั้งแต่แรก แน่นอนว่ามันต้องเจอกับ organization complexity และต้องใช้เวลานาน แต่ผมคิดว่าแรงต้านน่าจะน้อยกว่า
5. Evolutionary Change — ผมเชื่อใน Agile Organization Company ที่มีความคล่องตัวขั้นสุด แต่บอกตรงๆว่าผมก็ไม่รู้หรอกว่าหน้าตามันเป็นยังไง แต่ผมเห็นว่า Flight Levels มันเป็นเครื่องมืออีกตัวนึงที่มาช่วยค่อยๆ transform จากจุดที่องค์กรปัจจุบันเป็น ไปเป็นองค์กรที่ management อยากให้เป็น หรืออยากให้ดีขึ้น วิธีที่ผมไม่เห็นด้วยที่สุดคือการเปลี่ยน Org. Chart เป็นแบบบริษัทอื่นที่ทำแล้วดีตั้งแต่ครั้งแรกที่เริ่มปรับปรุงการทำงาน เพราะจากประสบการณ์ที่เจอมันเพิ่มปัญหาใหม่ในทุกจุดเลยในขณะที่ปัญหาเดิมไม่ได้หายไปไหน Flight Levels ก็เหมือนกับ Kanban ที่มันค่อยๆ ปรับ แน่นอนว่ามันใช้เวลา อาจจะ 5–10 ปี แต่ผมคิดว่ามันก็เป็นแนวทางที่ดีแนวทางนึง
6. Scaling Agile Team Tool — ผมมองว่า Flight Levels ก็เป็นเครื่องมือสำหรับการ Scale Agile Team แบบหนึ่งได้ (คือทำแค่ Level 2) ถ้าที่ไหนที่คำว่า Scrum มันฟังดูแสลงหู แต่มันต้องทำอะไรบางอย่างโดยเฉพาะกับการทำงานร่วมกันหลายๆทีม Flight Levels 2 ก็เป็นทางเลือกที่ไม่เลวเลย
7. สุดท้ายมันจะกลายเป็น Large Scale Scrum (LeSS) — อ้าว 555 ตั้งแต่ตอนที่เรียน, สอน, และใช้ Kanban ผมพบว่าแนวทางที่ผมมักจะเอามาใช้ improve ก็คือแนวทางของ Scrum เพราะสาเหตุของความไม่ Agile ก็คือการส่งต่อของข้าม Silo นี่แหละ ถ้าทลายมันได้ก็ไม่ต้องเสียเวลาเวิ่นเว้อใส่ process หรือ document ให้มากความ ผมจึงคิดภาพสุดท้ายไว้ว่ามันจะกลายเป็น LeSS Organization (some how) แต่ Flight Levels จะเป็นเครื่องมือระหว่างทางที่จะพาไปให้ถึงจุดนั้นครับ นอกจากเราจะเลือกวิธีทุบกำแพงเลยตั้งแต่ต้น หรือไปสร้างใหม่โดยข้ามข้อจำกัดขององค์กรไปเลย นั่นก็เป็นอีกเรื่องนึง

ก็หวังว่าจะได้ประโยชน์จากบทความที่ผม share ครับ ขอบคุณที่เข้ามาอ่านกันครับ