AXONS Presents Agile Thailand 2023 : Business and Developer together
ในทุกช่วงกลางปี ชมรมคนรัก Agile จะครึกครื้นกับงานฟรีอย่าง “Agile Thailand” เป็นพิเศษ ปีนี้จัดขึ้นในวันเสาร์ที่ 17 มิ.ย. ภายใต้ Theme “Business and Developer together” ย่อมาจาก Agile Principle ข้อ 4 ที่ว่า
“ Business people and developers must work together daily throughout the project “
โดยงานจะจัดในรูปแบบ Unconference เช่นเดิม และจัดแบบ Open Space โดยมี 5 Principles และ 1 Law
Principle ที่ว่านั้นง่ายมาก มีทั้งหมด 3 ข้อด้วยกัน
- Whoever comes is the right people คนที่มาคือคนที่ใช่
- Whatever happens is the only thing that could have สิ่งไหนเกิดขึ้นแล้ว สิ่งนั้นดีเสมอ
- Whenever it starts is the right time เริ่มเมื่อพร้อมจะเริ่ม
- Whenever it is over, it is over จบเมื่อพร้อมจะจบ
และ 1 กฎที่เรามีคือ กฎของเท้าสองข้าง หรือ Law of Two Feet ถ้าพบว่าตรงนั้นตัวเองไม่ได้ทำประโยชน์หรือเรียนรู้แล้ว ให้ใช้เท้าสองข้างของเราพาตัวเองไปที่อื่นด้วยความเคารพ
ปีนี้เราได้เจ้าภาพสนับสนุนสถานที่จาก Axons ซึ่งก็ตามชื่องาน “AXONS Presents Agile Thailand 2023 : Business and Developer together” จัดที่ True Digital Park West ชั้น 2 ติด BTS สถานีปุณณวิถีเลย
และเรายังมีผู้สนับสนุนอีกเยอะมากกก 🙏🏻
Agile for Business Squads
ในช่วงเช้าของวันผมเลือกเข้าห้อง Class Room 1 ที่ชวนคุยเรื่อง “Agile for Business Squads” นำโดยพี่ Kris KBank
พี่ Krist เล่าว่า KBank เป็นธนาคารที่มี Scale ใหญ่มาก ปัจจุบัน KBank มีหลาย Business Pilar แต่ละ Pilar จะมีหลาย Tribe จุดเชื่อมระหว่าง Pilar และ Tribe คือ Control Pilar และแต่ละ Tribe จะมีหลาย Squad ตามแบบ Agile ของ Spotify
Business Pilar | Growth Business Strategy
- เป็นกลยุทธ์ในการพัฒนาธุรกิจของ KBank โดยมีการทำงานเป็นกลุ่มจาก Tribe ที่มีเป้าหมายในการบรรลุตามเป้าหมายที่วางไว้
Control Pillar
- เป็นส่วนในการตรวจสอบและปรับปรุงประสิทธิภาพของการทำงาน เพื่อสนับสนุนให้ธุรกิจเติบโตไปในทิศทางที่กำหนด
Tribe | Key Business Objective
- เป็นกลุ่มคน จำนวนไม่เกิน 150 คน โดยจะทำงานเป็น Squad แต่ละ Squad จะมี Goal ของตนเอง และทำงานอย่างอิสระ
Squad | Cross-Function Team
- เป็นทีมที่ทำงานแบบ Cross-Function โดยประกอบด้วยคนจำนวนประมาณ 8–9 คน แต่ละ Squad จะมี Squad Lead ที่รับผิดชอบในการ Prioritize งาน
Chapter | Key Capability
- ส่วนมากเป็น ผอ. ผอว. ในฝ่ายต่าง ๆ (เช่น Product, Marketing, Data ฯลฯ) แต่ละสมาชิกใน Squad จะถูกสรรและมีสังกัดจาก Chapter นั้น ๆ เพื่อให้มีความเชี่ยวชาญในงานที่ทำได้
ใด ๆ คืออย่ายึดติดกับ Structure โดยเด็ดขาด ให้ Focus on Time and Focus on Budget แล้วค่อยคิด Scope ของงาน
Squad ไหนไม่มีความจำเป็น ยุบ Squad นั้นได้เลย ยุบในที่นี้คือยุบหายหมด ยุบทั้งทีม ยุบทั้ง Product ด้วย พยายามตัด Squad ให้น้อยลง แล้วใส่ Resource ใน Squad ที่เหลือแทน
ทุก 2 เดือน สมาชิกใน Squad สามารถเปลี่ยน Squad ได้ตามความสนใจ และในช่วงการย้าย Squad นั้น Chapter Lead ต้อง Make Sure ว่าสามารถ Transfer Knowleged ได้ การเลือกคนเข้า Squad ก็ให้ Squad Lead ตั้ง Goal Setting ก่อนแล้วค่อยเลือกคนเข้า
IT ใช้ MVP ค่อนข้างง่าย แต่ Business จะเข้าใจยากมาก ให้แก้ไขด้วยการให้ตั้ง Goal ให้ทั้ง 2 ฝั่งได้ผลประโยชน์ร่วมกัน
Team Hierarchy of Need
Session ต่อมาผมเข้าร่วมฟัง เป็น Session ที่พูดเรื่อง “ทำอย่างไรให้ทีมโต ?” โดยพี่ Chris จาก ThoughtWorks
Leader ทั่วไปแล้วจะมีด้วยกัน 2 แบบ
- Leader ที่เข้าไปตั้งแต่เริ่มสร้างทีม Leader ประเภทนี้ถ้าส่งไปทีมที่กำลังไฟไหม้อยู่ก็จะทำอะไรไม่ได้มากนัก
- Leader ที่เข้าไปเพื่อดับไฟในทีมตอนทีมเละ เช่นเดียวกัน Leader ประเภทนี้ถ้าส่งเข้าไปสร้างทีมตั้งแต่เริ่ม ก็จะทำอะไรไม่ได้มากเหมือนกัน
และ Teams ก็มีด้วยกันหลาย Level แบ่งเป็น
- Survival Level เป็นเลเวลที่ทีมเละมาก แค่ทีม Delivery ของได้ก็เก่งแล้ว ในเลเวลนี้ Leader ห้ามวาง Process ห้ามวาง Structure โดยเด็ดขาด แต่เน้นที่การช่วยทีมแทน
- Safety Level เป็นเลเวลที่ทีมเริ่มมี Consitency ระดับหนึ่งว่าทีมสามารถทำแบบนี้ไปได้เรื่อย ๆ Leader ที่เก่งในเลเวลนี้คือคนที่เก่งเรื่องวาง Process ให้ทีม
- Belonging Level ทีมต้องการพิสูจน์คุณค่าให้ทุกคนเห็น
- Extreme Level ทีมเริ่มมี Identity มี Culture เป็นของตัวเอง
Transition From Survival to Safety หยุดช่วยทีม ไม่ว่าจะเป็นการหยุดช่วย Coding หยุดช่วย Design หยุดทุกอย่างแล้วหันไปวาง Structure หรือวาง Process
Transition From Safety to Belonging ไม่ต้องคุมทีมแล้ว เพราะทีมรู้แล้วว่าควรทำอะไรบ้างตาม Process ที่วางไว้ ปล่อยให้ทีมได้ลองคุยกับ Stake Holder เน้นทำให้ Stake Holder เห็นคุณค่าของทีมให้ได้
Transition From Belonging to Extreme Leader ต้องช่วย Set Direction, Set Goal, Meaning, Aspiration ช่วยดัน Identity และ Culture ของทีม
จุดสำคัญในการสร้างทีม คือ ห้ามทำข้ามเลเวลเด็ดขาด ต้องค่อย ๆ สร้างทีมไล่ไปทีละเลเวล และ Leader ต้องนำหน้า Team อยู่ 1 ก้าวเสมอ เพราะถ้าทำทุกอย่างแทนทีมแล้วไม่ฝึกคิดล่วงหน้าให้เป็น ทีมจะไม่มีทางโตได้เลย
From Project to Product
มาต่อกันที่ Session ของพี่เจน จาก ODDS| ที่พูดถึงวิธีการเปลี่ยน Mindset จาก Project Mindset เป็น Product Mindset
มากกว่า 80% ของ Feature ไม่ถูกใช้งาน มีเพียง 20% เท่านั้นที่ถูกใช้จริง แล้วเราควรแก้ไขปัญหาเหล่านี้กันยังไงดีล่ะ ??
Project Mindset จะใช้สามเหลี่ยมทางด้านซ้าย คือ Focus ที่ Scope ก่อน Budget และ Time ซึ่งมัน Leads to Less Business Involvement, More Task Management. เพราะ Success ถูก Define ไว้ตั้งแต่ก่อนเริ่ม Project แล้ว
Product Mindset จะใช้สามเหลี่ยมทางด้านขวา คือ Focus ที่ Budget และ Time ก่อน จากนั้นค่อยคิดถึงเรื่อง Scope ของงานว่าจะทำได้ประมาณไหน
พี่เจนนิยามของที่จะ Releasable ได้ต้องประกอบไปด้วย 3 อย่างดังนี้
- Feature ต้องเพียงพอให้ User ใช้งาน
- End Customer สามารถใช้งานเองได้ด้วยตัวเอง ไม่ใช้เอกสารสอน ไม่ต้องเรียนรู้เยอะเพื่อที่จะใช้งาน
- Build Product ภสยใต้เวลาที่คาดหวัง โดยเวลาในที่นี้ไม่ได้หมายถึง Time ในสามเหลี่ยม แต่หมายถึง Time to Market ว่าถ้าไม่ทำตอนนี้เราจะเสียอะไรไปบ้าง
คำตอบของตอบคำถามข้างบนที่ผมสรุปได้คือ ถ้าเรา Focus ที่ Product มากพอ เราจะได้ของที่ต้องใช้งานจริง ๆ
อาชีพ Scrum Master สรุปว่าดีไหม (เมื่อ 10 ปีผ่านไป)
Session นี้เป็นของพี่เก๋ จาก ODDS| ที่มาแบ่งปันเกี่ยวกับอาชีพ Scrum Master จากประสบการณ์ตรง
เรามักจะได้ยินบ่อยครั้งว่าเมื่อ Team Self Manage ได้แล้ว Scrum Master จะตกงาน แต่ความจริงแล้วมันไม่เป็นแบบนั้นน่ะสิ เพราะอาชีพที่เราคิดว่าทำง่าย มันกลับมีความยากสลับซับซ้อนเต็มไปหมด และอาชีพนี้ในปัจจุบันก็มีความต้องการสูงมากด้วย
สิ่งที่ Scrum Master Focus มีอยู่ด้วยกัน 4 Area ประกอบด้วย
- Teams
- Product Owner
- Organization
- Development Practices
ในช่วงเริ่มต้น Area ที่ต้อง Focus มากที่สุด คือ Teams และ Product Owner หน้าที่ของ Scrum Master คือ การฝึกฝนให้ทีม Self Manage ตัวเองได้ จนทีมเริ่ม Delivery งานได้ ทำควบคู่ไปกับการเป็นโค้ชให้ Product Owner โดยให้คำแนะนำในเรื่องของ Scrum และการใช้ Product Backlog ให้เก่งที่สุด ช่วยในการสร้างความสัมพันธ์กับทีมโดยเฉพาะ
อย่าให้ความสำคัญแค่เฉพาะในความสัมพันธ์ระหว่าง Product Owner กับทีมเท่านั้น ความสัมพันธ์ของ Product Owner กับผู้ใช้จริงและลูกค้าก็ยังเป็นสิ่งที่ต้องการการสนับสนุนจาก Scrum Master เช่นเดียวกัน เพราะบางครั้งอาจเกิดกรณีที่ Product Owner ไม่เหมาะสม ในกรณีนี้ Scrum Master ควรช่วยให้องค์กรหา Product Owner ที่เหมาะสม ที่มีความเข้าใจผู้ใช้และลูกค้ามากเพียงพอ
การให้ความสนใจของ Scrum Master ต่อ Product Owner จะลดลงเมื่อ Product Owner เริ่มเข้าใจบทบาทของตนภายในองค์กรมากขึ้น
เมื่อ Team Self Manage ได้ Product Owner เริ่มเข้าใจบทบาทตัวเองและบทบาทของทีม Area ต่อมาที่ Scrum Master จะ Focus คือที่ Organization และ Development Practices
และเมื่อมีคนใหม่เข้ามาในทีมเพียงแค่คนเดียว Scrum Master ก็จะวนกลับไป Focus ที่ Team ใหม่ วนแบบนี้ไปเรื่อย ๆ
และบ่อยครั้งเมื่อ Team Self Manage ได้แล้ว และ Scrum Master เริ่มไป Focus ที่ระดับ Organization และ Development Practices แล้ว จากประสบการณ์ของพี่เก๋พบว่าทีมจะเริ่มเกิดอาการแปลก ๆ ไม่ว่าจะเป็นการ Delivery งานช้าบ้าง Product Owner เชื่อมั่นในทีมน้อยลงบ้าง Scrum Master ก็ต้องวนกลับมาทำหน้าที่เดิมใหม่
ใน Session นี้พี่เก๋ให้คำแนะนำเพิ่มเติมว่า คนที่อยากจะเป็น Scrum Master จริง ๆ อยากให้ลองเริ่มต้นจากการเป็น Team Member ก่อน เพื่อเก็บเกี่ยวประสบการณ์ให้ได้มากที่สุด เพราะ Scrum Master เป็นอาชีพที่ต้องอาศัยประสบการณ์มาตอบคำถาม หรือมาแนะนำทีมได้ และ Scrum Master แต่ละคนก็จะมีวิธีการแนะนำทีมที่แตกต่างกัน ตามแต่ประสบการณ์ของแต่ละคนที่พบเจอมา เพราะฉนั้น Cetificate ไม่ได้เป็นเครื่องการันตีเสมอไปว่าเราจะทำหน้าที่เป็น Scrum Master ได้ประสบความสำเร็จ แต่ไม่ใช่ว่า Cetificate ไม่สำคัญนะ มันยังสำคัญ แต่ไม่ใช่ที่สุด
และ Session สุดท้ายที่ผมได้เข้าร่วมของวันนี้นั่นก็คื้อออ …..
Scrum มูลบทแห่งสกรัม (ทฤษฏี)
Session นี้นำโดยพี่รูฟ จาก ODDS| ที่พูดถึง Scrum!!
Key ของ Session นี้ | ถ้ามันมีคนบ้าคนหนึ่งลุกขึ้นมาเต้นแล้วเรารู้สึกสนใจ สิ่งแรกที่เราควรทำ คือ รวบรวมความกล้า ลุกขึ้นยืน แล้วกระโดดออกไปบ้ากับเขา สิ่งสำคัญ คือ Movement ต้อง Public, Simple และ Easy to Follow แล้วคนที่เหลือจะตามมาเอง
เริ่มกันที่คำถามว่า “ทำไม Scrum ถึงเป็น Framework ที่ถูกใช้เยอะที่สุด ??” นั่นเป็นเพราะมัน Simple!! Key หลักของ Scrum คือมัน Easy to Start
Perfection Vision ของ Scrum บอกไว้ว่า
“ Create the organizational ability to respond to changes by being agility to deliver or change direction at any time without additional cost ”
บทสรุปรูปแบบการทำ Scrum ในไทยแบ่งได้ไม่กี่แบบตามรูปด้านล่างต่อไปนี้
พี่รูฟบอกว่าถ้ากำลังทำสิ่งนี้อยู่เรากำลัง Fail และได้โปรด Stop Copying This Model เถอะ เพราะเรา Copy มาไม่หมด เราแค่ Rename Organization แต่ทุกอย่างเหมือนเดิม
Fail ต่อมา…
สุดท้ายแล้วก็มี Organization Structure เหมือนเดิม เพียงแต่สร้างบริษัทใหม่ขึ้นมา ใช่มันเร็ว แต่คำถามคือกว่า Direction จากข้างล่างขึ้นข้างบน และข้างบนลงข้างล่าง สุดท้ายแล้วมันก็ช้าเหมือนเดิม มันไม่ Ability to Change และมันไม่ Change เลยต่างหาก
และนี่คือภาพที่สวยของรูปที่แล้ว แต่มันเริ่มยังไงกันเนี่ย?? มันจะดีมากถ้าอยู่ใน Organization ขนาดใหญ่ และต้องการที่ยืนให้กับทุกคน แล้วเขารู้สึกว่ามันไม่ได้มีอะไรเปลี่ยนแปลง
Better Version ของมันควรจะเป็นในลักษณะของ Flat Organizaiton โดยใน 1 Area มีคนดู 1 คน ทุก Sprint ต้องได้ของที่ Potentially Shipable ดีที่สุดคือขึ้น Production ไปเลย แล้วเอา Feedback วนกลับมาใส่ทีม
นอกจาก Perfect Vision แล้ว Scrum ยังมี Core Principle อีก 5 เรื่องด้วยกัน คนที่จะเป็น Scrum Master ต้องจำ Principle 5 ข้อนี้ให้ได้ว่าเราต้องสร้างทีมที่มี Character แบบนี้ให้ได้
Focus. Because we focus on only a few things at a time, we work well together and produce excellent work.We deliver valuable items sooner.
สิ่งที่สำคัญของ Focus คือของมันต้องพร้อม Releasable และไม่อยากเห็น Design Sprint, Dev Sprint, Test Sprint โดยเด็ดขาด
Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
อย่าพยายามบังคับให้ Delivery อย่างเดียว สิ่งที่สำคัญคือ Extend Ability ออกไปให้มากที่สุดเท่าที่จะมากได้ ใน Scrum เลยไม่มีการแบ่งตำแหน่ง มีแต่คำว่า “Teams” พยายามทำให้ทีมเกิดความท้าทายอยู่เสมอ เพื่อให้ทีมเก่งขึ้นได้เรื่อย ๆ
Openness. As we work together. we practice expressing how we’re doing and what’s in our way. We learn that it is good to express concerns so that they can be addressed.
ทีมที่ดีเวลาทำงานไปเรื่อย ๆ ต้องมีปัญหาตลอดเวลา และปัญหานั้นต้องถูกแก้อยู่เสมอ และทีมที่มีปัญหาคือทีมที่บอกว่าเราไม่มีปัญหา
Commitment. Because we have great control over our own destiny, we become more committed to success.
ทีมที่ทำ Scrum ต้อง Direction ตัวเอง ไม่ควรจะมีใครมาลากทีมว่าต้องเดินไปทางไหน เมื่อไหร่ก็ตามที่เราเลือกของที่เราอยากทำ เราจะรับผิดชอบมันสูงสุด
Respect. As we work together, sharing successes and failures, we come to respect each other and to help each other become worth of respect.
และเรื่องสุดท้ายพี่รูฟนำเสนอเรื่อง Keys สำหรับการ Adopt Scrum ว่า Product เป็น Byproduct ของทีม ถ้าทีมดี Product จะมีคุณภาพเอง
Key แรกคือ Shared Responsibility: Team ไม่ใช่แค่คนที่มานั่งรวมกัน
Key ต่อมาคือ Empowerment
Multi-Learning
และ Inspect and Adapt
ปิดท้ายด้วยคำคมสวย ๆ จากพี่รูฟที่ว่า “Scrum ก็เปรียบเหมือน มีด ในร้านทำอาหาร ซึ่งทำหน้าที่ในการหั่นได้ดีอยู่แล้ว ถ้าเราหั่นผักชิ้นใหญ่เกินไป เราควรจะฝึกการใช้มีดให้บ่อย ๆ เพื่อที่เราจะได้หั่นผักได้ตามที่ต้องการ อย่าโทษว่า มีดห่วย Scrum ก็เช่นกัน”
สุดท้ายนี้ขอบคุณ Sponsor ทุกท่าน ขอบคุณผู้จัดงาน ขอบคุณ ODDS| สถานที่ฝึกงานที่สนับสนุนการเติบโตของ Intern ตัวน้อยอย่างผม ขอบคุณพี่ ๆ ทุกท่านที่ชวนผมไป และอีกหลายท่านที่อาจไม่ได้เอ่ยถึง ขอบคุณมากครับ 🙏🏻
ไว้เจอกันใหม่ปีหน้าครับ 😁
