blogpom.me

ความเรียบง่าย หรือศิลปะในการทำงานอย่างพอเพียง นั้นสำคัญยิ่ง

ประโยคด้านบนนี่เป็นคำแปลที่ผมและเพื่อนๆ agile66 ได้ช่วยกันแปล principle ข้อ 10 นี้ไว้ที่ http://www.agilemanifesto.org/iso/th/ ซึ่งมาจากต้นฉบับว่า Simplicity--the art of maximizing the amount of work not done--is essential

ช่วยแรกๆที่ศึกษาอไจล์ ผมเข้าใจว่าคำว่า simplicity นี้หมายถึง การ design ที่เรียบง่ายไม่ยุ่งไม่เยอะ ไม่เผื่อสิ่งที่ยังมาไม่ถึง อารมณ์ emergent design รวมไปถึง TDD หรือ ATDD ที่ทำให้เราเขียน code แต่พอดีที่ทำให้ผ่าน test ไม่ฟุ้งไม่เผื่อ ซึ่งโดยรามก็เป็นเรื่องของ technical excellency 

ความล้มเหลวของวงการซอฟต์แวร์

ย้อนไปก่อนหน้าที่ผมจะรู้จักกับอไจล์ ผมโชคดีได้มีโอกาสไปร่วมงานกับโปรเจค core banking ของแบงค์รัฐบาลแห่งหนึ่ง ในโปรเจคนี้มีโปรเฟสเซอร์จากนอกคนหนึ่งเป็นที่ปรึกษา ผมจำชื่อท่านไม่ได้แล้ว แต่ผมยังจำได้แม่นถึงกราฟจากการบรรยายวันหนึ่งของท่านที่มีใจความว่า โปรเจคซอฟต์แวร์ส่วนใหญ่ในโลกนั้น 80% ไม่ล่มก็ไม่ทัน! ความรู้สึกตอนนั้นคือเราทำอะไรอยู่(วะ) แล้วมันจะรอดไหม สุดท้ายโปรเจคนั้นก็ไม่รอดจริงๆเพราะว่า vendor โดนไล่กลับประเทศ และมีการฟ้องร้องกันยืดยาว เสียเงินภาษีประชาชนไปผมว่าน่าจะเป็นพันล้าน ผมมาทราบทีหลังว่ากราฟที่โปรเฟสเซอร์เอามาเล่าให้ฟังนั้นมาจาก รายงานชื่อ CHAOS Report ของ Standish Group ซึ่งเป็นรายงานที่โค้ชหลายๆคนมักจะอ้างถึงในการสอนอไจล์ในปัจจุบัน

นอกจากข้อมูลเรื่องที่ว่าโปรเจคซอฟต์แวร์ส่วนใหญ่ไม่ประสบความสำเร็จตามที่วางแผนไว้แล้ว ยังมีอีกกราฟหนึ่งจาก CHAOS Report ซึ่งเรามักจะเห็นว่าได้รับการอ้างอิงถึงบ่อยๆ คือกราฟการใช้งานซอฟต์แวร์หรือ software usage report

ความสูญเปล่าของวงการซอฟต์แวร์

กราฟนี้บอกว่า ซอฟต์แวร์ที่เราๆท่านๆทำกันอยู่นี้ ถ้าพูดกันถึง feature ที่อยู่ในซอฟต์แวร์ มี 7% เท่านั้นที่จะมีคนใช้เป็นประจำ มี 13% ที่จะมีคนใช้บ่อยๆ มี 16% ที่จะใช้บ้าง มี 19% แทบจะไม่ถูกใช้เลย และมีถึง 45% ที่ไม่เคยถูกใช้เลย หลายคนที่เห็นกราฟนี้แล้วเริ่มตระหนักว่า 80% ของซอฟต์แวร์ที่เขากำลังทำอยู่นั้นแทบจะเป็นความสูญเปล่า ก็จะอึ้งไปพักใหญ่ ผมเองก็อึ้งไปเหมือนกันเมื่อได้เห็นกราฟนี้ครั้งแรก ความรู้สึกตอนนั้นคือเราทำอะไรอยู่(วะ)

กรณีศึกษาหนึ่งที่มักจะถูกหยิบยกมาอ้างถึงเรื่องความสูญเปล่าก็คือ Clippy หรือที่มีชื่อเป็นทางการว่า Microsoft Assistance

Microsoft ทุ่มทุ่นสร้าง feature นี้ด้วยเงินทุนมหาศาล แต่สุดท้ายก็ต้องถอน feature ออกเพราะไม่มีคนใช้ จริงๆจะเรียกว่าคนออกจะรำคาญหรือแม้แต่เกลียดเจ้า Clippy นี่เลยก็ว่าได้ จนสุดท้าย Microsoft ต้องถอน feature นี้ออกอย่างถาวร เพราะมันกลายเป็นตัวตลกของสังคมขนาดว่านิตยสาร Time เคยเขียนถึงว่าเป็น 1 ใน 50 สิ่งประดิษฐ์ที่ห่วยที่สุดของโลก

ในสมัยนั้นราคาของ Office นั้นแพงมากถ้าเทียบกับซอฟต์แวร์อื่นๆในยุคเดียวกัน แต่เอาเข้าจริงเวลาเราซื้อมาก็ใช้อยู่ไม่กี่ feature เลือกกดอยู่ไม่กี่รายการจากเมนู Microsoft อาจเป็นบริษัทที่มีเงินพอที่จะเอามาตำน้ำพริกละลายแม่น้ำแบบนี้ได้ แล้วบริษัทของเราเป็นอย่างนั้นหรือ? แล้วเราทำอะไรกันอยู่(วะ)

maximizing the amount of work not done

จะดีกว่าไหมถ้าเราไม่ต้องเอาแรงเอาเวลาไปทำสิ่งที่จะไม่มีคนใช้ การทำซอฟต์แวร์สมัยก่อนดูราวกับเป็นการเดาใจลูกค้าและมโนเอาเองคิดแทนลูกค้าว่าอยากได้อะไร เป็นเรื่องหน้าเศร้าที่หลายๆองค์กรในปัจจุบันก็ยังทำ product กันแบบนั้นอยู่ ยิ่งการแข่งขันสูง มีไอเดียกระฉูด ก็คิด product คิด feature กันออกมามากมาย แต่น่าเสียดายที่ส่วนใหญ่ก็ยังเอาแรงเอาเวลาไปกับความสูญเปล่า

หลายคนอาจจะเคยได้ยิน กฎ 80/20 หรือ กฎของพาเรโต้ ที่ว่าปกติเราลงแรงไป 20% ของทั้งหมดก็ตอบโจทย์ 80% ของเป้าหมายแล้ว ซึ่งก็หมายความว่าเราต้องการตอบโจทย์ให้ได้ครับทั้ง 100% เราต้องลงแรงเพิ่มอีก 4 เท่า ซึ่งดูเป็นการลงทุนที่ไม่คุ้มค่าเอาเสียเลย

สำหรับธุรกิจแล้วอไจล์นั้นมีชื่อเสียงในเรื่องการลด time to market แต่เคล็ดลับที่แท้จริงที่อไจล์จะช่วยธุรกิจแข่งขันหรือแม้แต่รอดตายได้นั้นคือการช่วยหา feature ที่ลูกค้าจะใช้จริงๆ 20% นั้นผ่าน early feedback ที่สม่ำเสมอ ถ้ามองในเชิงทุนแล้วถ้าเราหา 20% นั้นเจอแปลว่าเราลดต้นทุนได้ถึง 80% หรือใช้ต้นทุนเพียง 1 ใน 5 เท่านั้น

องค์กรที่ไม่ตระหนักถึงความจริงข้อนี้ก็มักจะมี product portfolio ที่เต็มไปด้วยความฝัน และสิ่งที่จะเกิดขึ้นตามมาก็คือแรงกดดันที่ถ่ายมายังพนักงานที่ต้องทำงานล่วงเวลาหามรุ่งหามค่ำเพียงเพื่อตำน้ำพริกละลายแม่น้ำแห่งความสูญเปล่า ในสถานการณ์เช่นนี้ แม้ทีมของเราจะมี technical excellency ขนาดไหน สิ่งที่ทีมทำไปก็ไม่ต่างอะไรกับการผลิตความสูญเปล่าที่มีคุณภาพด้วยความเร็วสูงเท่านั้น

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

ความแตกต่างของ IC Agile

สิ่งที่ทำให้ IC Agile น่าสนใจจริงๆนั้นคือความแตกต่างที่โดดเด่นของตัว IC Agile เอง

คุณ Ahmed Sidky ผู้ก่อตั้ง IC Agile กล่าวไว้ว่า ความแตกต่างนั้นคือ IC Agile ยึดตาม discipline ไม่อิงค่าย, มีหลายระดับทั้งแบบนั่งเรียนและต้องผ่าน peer review, มีหลากหลายสาย และ ร่างหลักสูตรด้วยปรมาจารย์อไจล์ทั่วมุมโลก ลองมาดูรายละเอียดกัน

ยึดตาม discipline ไม่อิงค่าย

ถ้าพูดกันตรงๆไม่อ้อมค้อมก็คือ IC Agile ไม่ยึดตาม Scrum Roles เหมือน Scrum Certificate ที่เป็นผู้นำตลาดอยู่ แต่จะยึดตาม discipline หรือสาขาวิชาที่เป็นความรู้เกี่ยวกับอไจล์ โดยไม่ได้แคร์ว่าคุณจะทำ Scrum, XP, Kanban หรืออะไรก็ตาม

ตัวอย่างเช่น IC Agile จะไม่มี certificate ของ Scrum Master แต่จะมี track ของ Agile Coaching ซึ่งเหมาะกับใครก็ตามที่ต้องการเรียนรู้เรื่องการโค้ช ซึ่งจะเป็นประโยชน์กับบทบาทในทีมเช่น project manager หรือ dev lead รวมทั้ง Scrum Master หรือ Agile Coach ไม่ว่าใช้อไจล์ตำราไหนก็ตาม หรือ IC Agile จะไม่มี certificate ของ Product Owner แต่จะมี track ของ Agile Value Management ซึ่งจะเป็นประโยชน์กับคนที่มีบทบาทใกล้ชิดกับลูกค้าเช่น Business Owner, Business Analyst, Product Manager หรือ Product Owner ในทีม มีหลากหลายสาย

ความหลากหลายของสาย (track) แบ่งตามสาขาวิชาต่างๆดังนี้

Agile Fundamental - พื้นฐานอไจล์ เป็นตัวเริ่มต้นของทุกสาย

Agile Development - สาย dev 

Agile Testing - สาย test

Agile Value Management - สำหรับผู้ทำงานใกล้ชิดลูกค้า อย่าง BA, PO

Agile Management - สำหรับท่านผู้จัดการทั้งหลาย

Agile Leadership - สำหรับท่านผู้บริหารระดับสูง

Agile Coaching  - สำหรับโค้ชระดับทีม

Enterprise Agile Coaching - สำหรับโค้ชระดับองค์กร อันนี้แยกออกมาจาก Coaching ระดับทีมอย่างชัดเจน

มีหลายระดับทั้งแบบนั่งเรียนและต้องผ่าน peer review

IC Agile มี certificate อยู่ 3 ระดับคือ

Professional - ซึ่งเหมือนกับ certification ทั่วไป คือมีเงินเรียนและทำข้อสอบว่าไม่ได้หลับตอนเรียน ก็จะได้ใบประกาศ

Expert - จะต้องสามารถแสดงให้คณะกรรมการหรือ peer ยอมรับได้ว่าเป็นของจริง อาจจะโดยผ่านการบันทึกเทปหรือแสดงสด!

Master - หรือระดับเทพ ผมยังไม่แน่ใจอันนี้นัก แต่เข้าใจว่าต้องไม่ใช่คนธรรมดา

ที่สำคัญคือทุก track การเรียนรู้มี certificate ทั้ง 3 ระดับ ไม่ว่าคุณจะมาสาย development , testing, coaching หรือสายอื่นๆก็ตาม

ร่างหลักสูตรด้วยปรมาจารย์อไจล์ทั่วมุมโลก

เนื้อหาของบทเรียนของผู้สอนแต่ละคนจะต่างกันไป แต่จะยึดกับ learning objective หรือเป้าหมายการเรียนรู้เดียวกันในแต่ละคอร์ส ซึ่ง learning objective เหล่านี้มีลิขสิทธิเป็น Creative Common และเผยแพร่ฟรีอยู่บนเวบ icagile.com 

จุดขายที่สำคัญของ IC Agile คือ learning objective เหล่านี้ได้รับการออกแบบจากปรมาจารย์อไจล์จากทั่วทุกมุมโลก อาทิเช่น 

Agile Development มี Alistair Cockburn หนึ่งในผู้ลงนาม Agile Manifesto

Agile Coaching มี Lyssa Adkins ตัวแม่ Agile Coaching ผู้แต่งหนังสือ Coaching Agile Team ที่โค้ชทุกคนควรอ่าน

Enterprise Agile Coaching มี Pete Behrens ผู้ก่อตั้ง Scrum Coach Retreat 

Agile Testing มี Janet Gregory ผู้เชี่ยวชาญ Agile Testing ผู้แต่งคัมภีร์ Agile Testing

Agile Value Management มี Shane Hastie ผู้เชี่ยวชาญเรื่อง Business Analyst และ Product Ownership 

บทสรุป

มาเรียน IC Agile กันไหมครับ ;-) ได้ยินมาว่าไม่มีวันหมดอายุและตอนนี้ก็มีคนถือ certification แล้วกว่า 18,000 คนแล้ว

ความตั้งใจของ Agile Bangkok Meetup คือจะเป็น meetup ของคนสนใจอไจล์แต่ที่จะแตกต่าง meetup อไจล์อื่นๆคือจะเน้นว่าเป็นพื้นที่พบปะของทั้งชาวไทยและเทศ ภาษาที่ใช้จึงจะเป็นภาษาอังกฤษ โดยรูปแบบจะเป็นการผสมผสานกันระหว่างการเชิญวิทยากรมาพูดกับการเสวนาหรือแม้แต่มาเล่นเกมกัน วันเวลานั้นจะขึ้นกับวิทยากรที่เชิญมาแต่คิดว่าอยากจะจัดให้มีขึ้นทุกๆเดือน ส่วนสถานที่กะจะเวียนกันไปและแต่ว่าในช่วงนั้นจะหาผู้ใหญ่ใจดีมาอนุเคราะห์สถานที่ได้ที่ไหน แต่ก็จะพยายามเน้นหาสถานที่ที่พวกเราเดินทางมากันได้สะดวก

อย่างครั้งล่าสุดนี้เราก็ได้คุณ Kluas Leopold มาพูดในหัวข้อ Kanban, Beyond Post-It and WIP Limit ครั้งนี้เราได้รับการสนับสนุนด้านสถานที่จาก ABAC จัดห้องไว้ 50 ที่ ลงทะเบียนมา 55 คน ปรากฏว่ามากันเต็มห้อง 50 คนเลย ซึ่งนับเป็นอัตราการมาเข้าร่วมงานฟรีที่ทุบทำลายกฎ 2/3 ที่ว่างานฟรีนั้นลงทะเบียน 100 คนจะมีจริงแค่ 66 คนเท่านั้น ด้วยเสียงตอบรับที่ล้นหลามอย่างนี้ แม้งานจะเป็นภาษาอังกฤษและหัวข้อก็ไม่ได้เป็นที่รู้จักกันเท่าไหร่ในบ้านเรานัก ทำให้ผมมีกำลังใจและความมั่นใจว่าจะทำ Agile Bangkok Meetup ไปอย่างต่อเนื่องได้ 

อีกทั้งในปีนี้ทาง Lean In Consulting ก็มีแผนจะนำคอร์สเรียนอไจล์ดีๆจากต่างประเทศที่แตกต่างจากคอร์สอไจล์ทั่วไปมาให้พวกเราได้เปิดกะลากันถึงในบ้านอย่างต่อเนื่องอยู่แล้ว เราเปิดตัวด้วยคอร์ส Applying Kanban ของคุณ Kluak Leopold จากกรุงเวียนนาประเทศออสเตรีย ซึ่งไหนๆเขาก็เดินทางกันมาไกลแสนไกลแล้ว มาทั้งทีจะมาจัดคอร์สเรียนกับคนแค่หยิบมือเดียวก็ดูจะเสียเที่ยว เราจึงมีนโยบายว่าชวนใครมาสอนแล้วก็จะชวนเข้ามาเป็นแขกใน Agile Bangkok Meetup ด้วย

ปลายเดือนมีนาคมนี้เราก็จะมีอาคันตุกะอไจล์อีกท่านหนึ่งจากแดนอาทิตย์อุทัย คือคุณ Kiro Harada จะมีเปิดคอร์ส Improving Scrum with Kaizen ซึ่งเป็นคอร์สที่คนทำ Scrum มาซักพักแล้วรู้สึกว่ามันยังติดหล่มอะไรซักอย่างอยู่ไม่ควรพลาด ในไตรมาสที่สอง เราก็กำลังทาบทามปราชญ์อไจล์ท่านอื่นมาสอนเรื่อง Product Owner และ Agile Testing และเราก็ตั้งใจว่าจะมีมาเรื่อยๆตลอดทั้งปี ซึ่งก็แน่นอนว่าแต่ละคนที่ชวนมาสอน เราก็จะชวนมาเป็นแขกใน Agile Bangkok Meetup อย่างต่อเนื่อง

ทีนี้ Outcome Driven Development ไม่ได้หมายถึงแค่การทำ product แต่รวมไปถึงการ coaching ด้วย David เล่าว่าปกติท่าของเขาหลังจากเข้าไป assess team แล้วก็จะทำ Coaching Plan ส่งให้ลูกค้า โดยมีเนื้อหาคร่าวคือ

WHEN - กะว่าจะใช้เวลานานแค่ไหน

WHERE - จะเริ่มจาก project หรือ product ไหน

WHAT - จะใช้ท่าไหน

HOW - จะวัดความสำเร็จได้อย่างไร?

ที่เด็ดมันอยู่ตรงวัดความสำเร็จนี่เอง ซึ่งจุดนี้ผมแทบจะไม่เคยเอามาคุยกับลูกค้าเลยในตอนเริ่มต้น แน่นอนว่า WHEN/WHERE/WHAT/HOW เหล่านี้มักจะไม่เป็นไปตามแผนที่วางไว้ แต่การได้มองเห็นภาพร่วมกันและค่อยๆปรับกันไปย่อมจะทำให้เพิ่มโอกาสให้งานนั้นประสบความสำเร็จมากขึ้น ผมตั้งคำถามไว้ตอนต้น Scrum Coaching Retreat ว่าจะวัดความสำเร็จของโค้ชอย่างไร ผมว่าผมได้คำตอบแล้ว

David เรียกกระบวนการนี้แบบขำๆว่า Test Driven Coaching `:)

Linda บอกว่าสิ่งที่ตรงข้ามกับ Agile Mindset ก็คือ Fixed Mindset ที่คิดว่าเราคงทำนั่นไม่ได้ ทำนี่ไม่ได้ เธอเล่าถึงการทดลองทางจิตวิทยาที่อยู่ในหนังสือ Mindset ของ Carol Dweck ว่าการทดลองแบ่งนักเรียนเป็นสองกลุ่ม กลุ่มหนึ่งมี Fixed Mindset กับอีกกลุ่มมี Agile Mindset แล้วให้ทำข้อสอบยากง่ายสลับไปมาสี่ห้ารอบ เป็นที่หน้าตกใจว่ากลุ่มที่มี Fixed Mindset นั้น ราวกับจะพูดกับตัวเองอยู่ตลอดเวลาว่าทำไม่ได้ทำไม่ได้ เลือกที่จะทำข้อสอบที่ง่ายเพราะไม่อยากจะคะแนนลด ดูไม่ได้ แถมบอกคนอื่นว่าอย่าได้พยายามเลย มันยาก ในขณะที่กลุ่มที่มี Agile Mindset นั้นมีความอยากที่จะทำข้อสอบที่ยากขึ้น และสามารถให้กำลังใจคนอื่นให้สู้ไปด้วยกันได้ (ในหนังสือ Mindset ใช้คำว่า Growth Mindset แต่เธอเอามาเรียกว่า Agile Mindset ให้เข้ากับบริบท)

ผมก็นั่งงงอยู่พักใหญ่ว่าเขาแบ่งกลุ่มคนออกแบบนี้ได้ยังไง หรือเราฟังไม่ทันตอนไหน แต่ก็ต้องอึ้งไปพักใหญ่เมื่อ Linda เฉลยว่าวิธีการทดลองนี้แค่สุ่มแบ่งนักเรียนเป็นสองกลุ่ม แต่กลุ่มที่ถูกกำหนดให้เป็น Agile Mindset นั่น ตอนทำข้อสอบเสร็จ ครูจะบอกว่า "เธอต้องเตรียมตัวมาดีมากแน่เลย" ในขณะที่กลุ่ม Fixed Mindset นั้น ครูจะบอกว่า "เธอต้องเก่งมากๆแน่เลย" แค่นี้เอง!!! 

Linda บอกว่าเคล็ดลับในการทำให้คนมี Agile Mindset ก็คือการชื่นชมที่ความพยายาม (Praise The Effort) ไม่ใช่ชื่นชมลอยๆว่าเก่งจัง เหมือนที่เราชอบชมเด็กๆว่าเก่งจังเลย ซึ่งจริงๆจะกลายเป็นหลุมที่เราขุดให้เด็กจมอยู่กับความรู้สึกที่ต้องการดูดี ยอมรับความผิดพลาดไม่ได้ ไม่กล้าเสี่ยง (Linda ให้ไปอ่าน How Not To Talk to Your Kids ของ New York Magazine ต่อ)

เป็นที่หน้าเศร้าว่า Fixed Mindset นี้ กลายเป็นบรรทัดฐานของสังคมปัจจุบันไปแล้ว ไม่ว่าจะเป็นระบบตัดเกรดในระบบการศึกษาหรือระบบ Rank & Yank ในที่ทำงานคือคนเก่งเอาไว้คนห่วยเอาออก แต่การทำลองของ Dweck ก็ทำให้เราเห็นแล้วว่า เราสามารถสร้าง Agile Mindset ได้ และมันก็เป็นหน้าที่ของเราแล้ว หลังจากได้ฟังเธอพูดจบ :-)

หัวข้อที่สองที่ผมไปฟังมาคือ Introduction to LeSS (Large-Scale Scrum) ซึ่งเป็น framework ในการขยาย Scrum สำหรับองค์กรใหญ่ โดยคุณ Bas Vodde ซึ่งเป็นต้นตำหรับในการคิด LeSS ร่วมกับ Craig Larman

Bas บอกว่าเขาตั้งใจทำ LeSS ให้เป็น Shu คือบอกกันไปเลยว่าต้องทำอะไร แต่จะตั้งต้นโดยมีข้อกำหนดน้อยที่สุด เพื่อให้แต่ละบริบทนำไปต่อยอดเอง (ซึ่งต่างกับของอีกค่ายคือ SAFe ซึ่งจะเป็นอารมณ์จัดไปเยอะๆกันแล้วค่อยเลือกมาใส่)

ถ้ามี Scrum ทีมหลายๆทีม LeSS บอกว่าให้มี Product Backlog หนึ่งเดียวและ Product Owner หนึ่งคน โดยแต่ละทีมมี Sprint Backlog ของตัวเอง แต่ทำ Sprint ไปพร้อมๆกัน คือเริ่มและจบพร้อมกัน การมี Product Backlog เดียวจะช่วยให้ทุกทีมมองภาพใหญ่ร่วมกันได้

ถ้ามีทีมเกิน 8 ทีม จะมีท่าพิเศษที่เรียกว่า LeSS Huge จะมี Area Product Owner เข้ามาช่วย และ ceremony จะมีทั้งที่ส่งตัวแทนทีมไปร่วมและต้องคุยด้วยกันหมดทุกคน ใครสนใจรายละเอียดให้ไปดูเพิ่มเติมได้ที่ http://less.works

ผมลองถาม Bas ด้วยว่าให้เทียบ SAFe กับ LeSS แต่เขาตอบแบบสั้นๆว่า LeSS is more save ราวกับจะบอกว่า SAFe นั้นไม่ปลอดภัย อืม...

หัวข้อที่สามของวันนี้คือ All written lean practices are wrong โดย Kiro Harada จากญี่ปุ่น ดูประวัติคนพูดแล้วเขามาจาก manufacturing และดูหัวข้อแล้วมันน่าสนใจ เลยเขาไปลองซะหน่อย จริงๆมาเข้าแล้วผมรู้สึกว่า Kiro จะบอกว่า Lean Practices ที่เราทำกันไม่ถูกมากกว่าที่เขียนไว้ไม่ถูก 

ตอนแรก Kiro ให้ลองทำ 5 Why กันที่โต๊ะโดยปัญหาจากประสบการณ์จริง แต่ก็โดนตบท้ายด้วยคำถามว่า ที่เจอสาเหตุกันมาเนี่ย มันเป็นสาเหตุของปัญหาจริงๆหรือ ถ้ารู้อยู่ว่าไม่ใช่แล้วตอบมาทำไม ถ้าใช่จริงๆเคยทำอะไรกับมันไหม เคยแก้ไขมันไหม สาระของ 5 Why ที่ Kiro บอกคือ ถ้ายังไม่เจอ root cause ก็หาต่อไป ถ้าเจอแล้วก็จงจัดการแก้มันซะ ไม่ใช่สักแต่ตั้งคำถามหรือมัวแต่หาข้อแก้ตัว

practice ต่อมาที่นำมาพูดถึงคือ Jidoka หรือ autonomation หรือ stop the line ซึ่ง Kiro สาธิตโดยเอาคนมาเล่นเกมทำนอง Ball Points แบบมีงานแทรก แล้วสรุปด้วยการกัดจิกว่า เครื่องจักรที่เป็น autonomation เครื่องแรกคือเครื่องทอผ้าของโตโยต้าสมัยสงครามโลก ที่สามารถหยุดการทำงานได้เองเมื่อมี defect แต่บรรดา developer ทั้งหลายยังมัวแต่จะมุ่งทำโค้ดโดยไม่คิดจะหยุดเมื่อมี defect ยิ่งทำก็ยิ่งปล่อย defect ออกมา อย่างนี้ก็ไม่ได้ฉลาดไปกว่าเครื่องทอผ้าโบราณแต่อย่างใดเลย

Kiro พูดถึง Kaizen เล็กน้อยในช่วงท้ายว่า Kaizen ต้นตำหรับนั้นมีจุดมุ่งหมายจะปรับปรุงให้การทำงานง่ายขึ้นและปลอยภัยขึ้นเพื่อจะได้มีเวลามาปรับปรุงอีกอย่างสม่ำเสมอ 

ผมไม่เก็ททั้งหมดที่ Kiro พูด อาจเป็นเพราะผมฟังสำเนียงเขาไม่เข้าใจทั้งหมดด้วย แต่ผมชอบ character ของเขานะ ดูกวนประสาทมาก แถมยังหัวฟูให้อารมณ์โปรเฟสเซอร์สติเฟื่องด้วย ได้ข่าวว่าเขาอาจจะมา Coach Retreat ด้วย น่าจะมันส์

หัวข้อที่สี่คือ Applying Agile Development Practices in Distributed Teams -ของ Jutta Eckstein จากเยอรมันนี สมัยอยู่รอยเตอร์ผมเคยซื้อหนังสือเกี่ยวกับ Distributed Team ของเธอมาอ่าน เลยอยากมาเจอตัวจริง แต่ขอสารภาพว่าลืมไปแล้วว่าหนังสือเธอว่ายังไงบ้าง

แอบประหลาดใจเล็กน้อยว่าเครื่องมือที่เธอบอกว่าจะช่วย Distributed Team ที่อยู่กันคนละซีกโลกนั้นไม่ใช่ Cisco Telepresence หรือ Skype VDO Call แต่เป็น engineering practices อย่าง TDD, Pair Programming, Contineous Integration และ Collective Code Ownership ซึ่งอีกนัยหนึ่งมันก็คือเครื่องมือช่วยในการสื่อสารของ developer เพราะ developer นั้นสื่อสารกันด้วย code

หัวข้อสุดท้ายของวันนี้ก็คือ Interpreting the Unwritten Rules - or are they Guidelines ของ Shane Hastie จากนิวซีแลนด์ ตอนแรกผมดูแล้วว่าชื่อคุ้นๆ ไปขุดดูก็พบว่าเป็นคนที่ผมติดต่อด้วยตอนแปล Agile Manifesto เป็นภาษาไทย และเป็นคนตรวจบทความที่ผมเคยเขียนขึ้น InfoQ ไปหนึ่งบทด้วย

Shane บอกว่าเรามองโลกผ่านฟิลเตอร์หลายๆตัวซึ่งแต่ละคนก็จะมองเห็นต่างกันไป ฟิลเตอร์ที่ว่านี้ก็มี วัฒนธรรม บุคลิก สิ่งที่เราให้คุณค่า ความรู้สึก และ สถานะการณ์

ฟิลเตอร์เหล่านี้มักจะกลายเป็นกฎ (rules) ในการมองโลกของแต่ละคน แต่ปัญหาของกฎนั้นคือมันจำทำให้เกิดความไม่ยืดหยุ่น เพราะเราจะไปยึดติดกับมันและคิดว่ามันเปลี่ยนแปลงไม่ได้ ซึ่งจะกลายเป็นปัญหาชีวิตในที่สุด Shane แนะนำวิธีการเปลี่ยนกฎเป็นข้อแนะนำ (guideline) ตามวิธีที่เขาได้มาจาก Gerald Weinberg กับ Johana Rothman ที่ AYE Conference (ดูชื่อคนจัดแล้วน่าไปมากๆ)

Shane บอกให้ลองเอากฎที่มักจะทำไม่ค่อยได้มาลองเปลี่ยนเป็นข้อแนะนำดู ผมเลยลองกับปัญหาการติดมือถือของผม

(state rules percisely)

A) I must put down my mobile

(must -> can always) B) I can always put down my mobile

(always -> sometimes) C) I can sometimes put down my mobile

(identify 3 circumstances that matter) D) I can put down my mobile 1. I am having a meal with my family 2. I am having a meeting with my teams 3. I am playing with my son

ซึ่งท่านี้สามารถนำไปใช้ได้อย่างดีกับทีม โดยเฉพาะเวลาที่ retrospective แล้ววนอยู่ในอ่างไม่ไปไหนซักที

Technical Track - ว่าด้วยเรื่องทางเทคนิค

Do and Don't for Continuos Delivery โดยคุณหยี (ไมเคิล) หนึ่งในขุนพลคนไทยจาก ThoughtWorks ที่บินตรงมาจากอเมริกา เพื่อมาเล่าสู่กันฟังของสิ่งที่ควรและไม่ควรการทำ Continuous Delivery

Implementing Agile Engineering Practices เป็นการเล่าประสบการณ์จริงในการใช้ Agile Engineering Practices จากคุณ Alan Atlas ซึ่งเป็น Certified Scrum Trainer และ Certified Scrum Coach จากอเมริกาที่สอนและใช้ Scrum มามากกว่า 10 ปี

Abstraction Is A Communication Tool, Period โดยคุณ Terry Yin จาก Odd-e สิงค์โปร์ ซึ่งเป็นผู้ที่เรียกเสียงปรบมือและเสียงหัวเราะจากผู้ฟังมากมายจากงานปีที่แล้ว มาปีนี้เขาจะมาเล่าให้ฟังว่าทำไม Abstraction ซึ่งเป็นเครื่องมือสื่อสารที่ในการพัฒนาซอฟต์แวร์นั้นเป็นสิ่งสำคัญแต่ก็ยังไม่เพียงพอในการแก้ปัญหา

Enterprise Agile Pitfalls โดยคุณวโรกาศ จาก Cobolt Group หรือที่เรารู้จักกันดีในชื่อนนท์แห่งอไจล์ 66 เจ้าของหนังสือ Agile Pitfalls หนังสืออไจล์เล่มแรกของไทย  บินตรงมาจากอเมริกาอีกเช่นกัน คราวนี้นนท์จะมาพูดถึงหลุงพลางของการทำอไจล์ในระดับ Enterprise รวมไปถึงการขยาย Scrum ให้สามารถใช้ได้กับหลายๆทีมพร้อมกันในองค์กร

Enterprise Track - ว่าด้วยอไจล์ในองค์กรใหญ่

Enterprise Scaling Strategy โดยคุณ Maris Prabhakaran จาก Legerity Consulting Services ประเทศอินเดีย จะมาว่ากันในหัวข้อที่คนทำอไจล์ในองค์กรใหญ่พลาดไม่ได้ ทำอไจล์ในหนึ่งทีมให้เวิร์คนั่นก็ไม่ง่ายอยู่แล้ว ถ้าจะทำให้ประสบความสำเร็จในระดับองค์กรจะมีกลยุทธอย่างไร

Agile Business โดยคุณ John Okoro จาก Rally Software (สาขาสิงค์โปร์) ยักษ์ใหญ่ผู้นำตลาด Agile Tool ของโลก จะมาเล่าสู่กันฟังว่าอไจล์จะช่วยปฏิวัติธุรกิจคุณได้อย่างไร งานนี้ผู้บริหารที่สนใจอไจล์ไม่ควรพลาดด้วยประการทั้งปวง

The Principles of Agile Matrices โดยคุณ Sunil Mundra จาก ThoughtWorks ประเทศอินเดีย ที่ฝากผลงานไว้ให้หลายคนติดใจตั้งแต่งานปีที่แล้ว จะมาไขข้อข้องใจที่คนทำอไจล์หลายคนสงสัย นั่นคือถ้าเราทำอไจล์แล้วจะวัดผลกันอย่างไร

The Lost Art of Building Great Rroduct โดยคุณกัน อรุณเทพ จาก Bridge Asia ที่จะมาแชร์เคล็ดลับที่จะทำให้ทีมที่ทำ product ด้วยอไจล์ประสบความสำเร็จ

Startup Track - ว่าด้วยอไจล์กับ Startup

What's The Big Idea? โดยคุณพีท UX Expert จาก ThoughtWorks ออสเตรเลีย จะมาแนะนำให้เรารู้จักกับเทคนิค Collaborative Sketching ซึ่งเป็นเทคนิคที่มีประสิทธิภาพที่ใช้ในการเปลี่ยนไอเดียที่ล่องลอยของลูกค้ามาเป็นเอกสารความต้องการที่จับต้องได้ในเวลาอันรวดเร็ว รวมไปถึงการแนวทางในการทดสอบสมมุติฐานว่าตลาดหรือลูกค้าต้องการจริงๆหรือไม่ ผู้ที่สนใจ Lean Startup ไม่ควรพลาด

Practical Guide for First Time Product Owners โดย คุณ Alex Phelps ซึ่งจะมาอธิบายคุณสมบัติพื้นฐานของ Product Owner และแชร์ประสบการณ์จริงที่หาฟังไม่ได้ง่ายนักของการทำงานเป็น Product Owner ที่ Proto Marketing

Moving from Waterfall to Agile โดย คุณ Michal Juhas จะมาเล่าประสบการณ์ตรงในการปรับทีมจาก Waterfall ไปเป็นอไจล์ของ HotelQuickly ซึ่งเป็น startup ที่ร้อนแรงที่สุดรายหนึ่งที่มีทีมพัฒนาอยู่ในเมืองไทย ที่เมื่อเร็วๆนี่ TechCrunch เพิ่งลงข่าวไปว่าได้เงินลงทุนเพิ่มอีก 4.5 ล้านเหรียญสหรัฐ!

Gamification of Agile Projects โดยคุณ Panditi Prabhaker Rao จาก CPA Global ประเทศอินเดีย จะมาเล่าถึงการทำให้การทำโปรเจคอไจล์สนุกเหมือนการเล่นเกม

Mind Track - ว่าด้วยอไจล์กับปรัชญา จิตวิทยา Flow และ ฟาร์ม!

Agile and Waterfall from the view of Plato and Aristotle คุณ Fredrik Carleson จาก UNOPS ซึ่งเป็นหน่วยงานทำโปรเจคไอทีให้สหประชาชาติ จะมาเล่าให้เราฟังว่าแท้ที่จริงแล้วแนวคิดอไจล์นั้นมีต้นกำเนิดมาจากปรัชญากรีกโบราณอย่างไร  ห๊ะอะไรนะ?!?!

Agile and Psychology โดยคุณบี จาก Thomson Reuters จะมาเล่าถึงอไจล์ในอีกแง่มุมทีสัมผัสได้แต่มักจะไม่พูดถึงกัน นั่นคือเรื่องอไจล์กับจิตวิทยา

Hyper Productivity มาค้นหาวิธีปลดปล่อยพลังซุปเปอร์ไซย่าในตัวคุณ โดยจั๊วจาก Odd-e หัวข้อนี้ไม่ต้องเท้าความมากเพราะเปิดทีไรคนก็แน่นห้องทุกที 

Implementation of Agile in real life example and development of farm house อไจล์ไม่ได้ใช้กับโปรเจอซอฟต์แวร์เท่านั้น คุณ Yogesh จาก AllScripts ประเทศอินเดีย จะเล่าให้เราฟังว่า ทำฟาร์มด้วยอไจล์นั้นทำอย่างไร

เวอร์ชันทดลองเล่นฟรีนั้นมีข้อจำกัดอยู่ แต่ก็ใจดีพอสมควรคือให้ทำคลิปความยาวไม่เกิน 30 วินาที มี template ให้พอประมานแต่มีเพลงประกอบให้เลือกเยอะมาก แถมยังให้ export ไป YouTube ได้เลยอีกด้วย การทำวิดีโอนั้นไม่มีลูกเล่นอะไรมาก คือใน frame นั้นไม่ใส่รูปหรือคลิปก็ใส่ข้อความสั้นๆ ด้วยความที่ทำอะไรไม่ได้มากก็เลยทำให้มันใช้ค่อนข้างง่าย การออกแบบของ app เองก็เรียบง่ายสะอาดตา

อย่างที่เราทราบกันดีว่าอไจล์ไม่มีสูตรตายตัว ผมจะขอเล่าท่าที่ผมคิดว่ามันน่าจะใช้ได้ให้ฟังก็แล้วกันนะครับ สมมุติว่าทีมเรามี capacity อยู่ 40 point คือใน Sprint หนึ่งๆปกติจะ burn ได้ราว 40 point ทำไปกลาง Sprint มีงานแทรกฟ้าประทานเข้ามา คุยกับ PO แล้วจำเป็นต้องทำ ณ บัดนาว ไม่งั้นจะเกิดวิกฤติ สิ่งที่ควรทำก่อน ถ้าไม่ได้คอขาดบาดตายขนาดระบบล่ม คือการปรับแผน (Replan) ว่า Sprint นี้ยังจะมีอะไรเสร็จอยู่บ้าง ในการปรับแผนก็ต้องทำการ estimate งานแทรกนี้ว่ามีขนาดกี่ point แล้วถ้าปกติแตก task ลงชั่วโมงกันด้วยก็ว่ากันไปตามปกติ เสร็จแล้วก็มาดูกันว่าผลกระทบคืออะไร มีของเข้าก็ต้องมีของออก ถ้าไม่เอาของออกก็ต้องทำงานล่วงเวลากันแน่นอนเพราะเราวางแผนไว้เต็ม Sprint ตั้งแต่แรก การทำงานล่วงเวลาเป็นครั้งคราวเป็นเรื่องปกติ แต่ถ้าทำกันเป็นประจำก็แน่นอนว่าไม่นานทีมก็คงล่มสลาย

อย่างไรก็ตาม ของใหม่เข้ามา 8 point ไม่ได้แปลว่าจะต้องเอาของออกไป 8 point ทั้งนี้อยู่ที่จังหวะที่ Replan ว่าทีมเห็นว่าอย่างไร อย่าลืมว่ามันไม่มีอะไรเป๊ะ

หลายๆทีมเข้าใจหลักการนี้ แต่สิ่งที่มักจะไม่ค่อยทำกันคือการ track ว่า Unplanned Story มีผลกับ Planned Story และภาพรวมของ Release อย่างไร ปัญหาที่จะเกิดคือผู้บริหารหรือ stakeholders ที่อยู่นอก Sprint ก็จะไม่เห็นภาพและไม่มีความเข้าใจว่าทำไม project ถึง late เครื่องมีอที่ช่วยเรื่องนี้ได้ดีมากคือ Release Burndown (หรือ Burnup) Chart ซึ่งจะได้มาบล๊อกกันให้อ่านกันต่อไป

ยุ่ง ก็หมายถึงความเสี่ยง (Risk) ที่เกิดขึ้นเนื่องจากความยุ่งยากของ Story นี้ หลายๆครั้งเราไม่รู้แน่นอนในเรื่องบางเรื่อง ก็อาจจะต้องตั้งสมมุติฐานให้โหวตให้ Point ไปก่อน ถ้าจะให้แปลงเป็นชั่วโมง จะเห็นได้ชัดว่าส่วนนี้แทบจะไม่สามารถประเมินได้เลย

ยาก ก็หมายถึงความซับซ้อน (Complexity) ของ Story ซึ่งจะใช้เวลานานแค่ไหนก็ขึ้นกับทักษะของคนทำ ถ้าจะเทียบเป็นเวลา ลองคิดว่าให้มือใหม่ทำอาจจะหลายวันในขณะที่คนมีประสบการณ์อาจจะแค่ไม่กี่ชั่วโมง

เยอะ ก็หมายถึงปริมาณงาน (Size) ซึ่งจริงๆแล้วดูเหมือนจะเป็นเป็นส่วนเดียวที่เทียบเป็นเวลาได้

สิ่งที่โค้ชกรแนะนำไปคือการทำงานร่วมกันนั้นทำได้แน่นอนแต่ไม่แนะนำให้ยุบทีมรวมกันกับลูกค้า เพราะจะทำให้ team synergy ที่สั่งสมมาพังไปเลย สิ่งที่ควรจะทำคือเป็นทีมแฝดที่ทำงานคู่ขนาน เอางานมาใส่คนไม่ใช่สลายเอาคนไปใส่งาน ทำงานแยก Sprint กันแต่ sync กันคือเริ่มและจบพร้อมกัน ถ้างานแยกกันขาดก็ควรจะแยก Product Backlog กันไปเลย โหวต story point ก็แยกกันไปเลยเพราะมันก็คือคนละทีม

แต่ถ้าแยกไม่ขาดจะมี Product Backlog เดียวก็ได้ ซึ่งจะทำให้ต้องโหวตด้วยกันหมด จะทำให้เห็นภาพรวมร่วมกัน แต่ท่านี้จะทำให้ใช้เวลาในการโหวตนานเพราะคนเยอะ วิธีที่อาจจะช่วยได้คือส่งตัวแทนมาโหวตแทนที่จะใช้ทุกคน สำหรับ Sprint Planning โดยเฉพาะ Part I และ Grooming ก็ควรทำด้วยกัน ส่วน Sprint Planning Part II, Review, Retro และ Stand-up จะรวมจะแยกก็แล้วแต่

การที่ทีมหลายๆทีมมาทำงานร่วมกันแล้วเกิดการเรียนรู้ซึ่งกันและกันระหว่างการทำงานเป็นเรื่องที่ดี ในแวดวงอไจล์มีศัพท์เฉพาะเรียกท่านี้ว่า Cross-Pollination แต่ก็พยายามยัดเยียดให้เกิดมากไปก็เป็นสิ่งที่พึงระวัง ไม่งั้นอาจพังไม่เป็นท่า