#agilesg

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 แล้ววนอยู่ในอ่างไม่ไปไหนซักที

Kent ทิ้งเรื่องเล่าไว้เท่านี้ก่อนแล้วก็มาบอกว่า ในความหมายของ Kent คำว่า Ease ของเขาหมายความถึงสภาวะที่สบายๆไร้กังวลและพร้อมลุย เขาเล่าว่าแต่ไหนแต่ไร ในหัวเขาจะมีเสียงสองเสียงคอยพูดกับเขา เสียงหนึ่งจะบอกว่าเขาเป็นสุดยอด สิ่งที่เขาทำนั้นไม่มีใครในจักรวาลนี้ทำได้แล้ว แต่ในบางครั้งก็จะมีเสียงจากอีกฝั่งหนึ่งบอกว่าเขาเป็น coder ที่แย่ที่สุดในโลก 

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

Kent บอกว่าสภาวะเอกขเนกของเขาจะเกิดได้ถ้าเขา

ได้ทำงานมีความหมาย - Kent เคยถาม dev คนหนึ่งที่เขียน sequence diagram ว่าทำไมต้องเขียน เขาตอบว่าไม่รู้เหมือนกัน ก็เห็นว่า RUP บอกว่าต้องเขียน Kent บอกทำงานแบบนี้ไม่เรียกว่ามีความหมาย เขายังไม่วายแซว RUP ซึ่งย่อมาจาก Rational Unified Process ว่า ไม่เห็นมันจะ Rational หรือ Unified ตรงไหน แต่มันเป็น Process แน่ๆ สำหรับงานที่มีความหมาย เขายกตัวอย่างที่เขาทำให้เวลาของ FB Chat transaction ลดลง 70 วินาที ถ้าลองเอา 70 วินาทีคูณกับจำนวนผู้ใช้ทั้งหมดนี่จะเป็นจำนวนมหาศาลเลย

ได้เขียนโค้ดที่เวิร์ค - TDD ช่วยตรงนี้ได้มาก ทำให้มั่นใจว่าโค้ดเราเวิร์ค ทำให้เขารู้สึกดีกว่าการเขียนโค้ดที่ไม่รู้ว่ามันจะออกหมู่หรือจ่าเป็นไหนๆ

มีความภูมิใจในงานที่ทำ - งานที่เขาไม่อายที่จะโชว์ให้คนอื่นดู เช่นเขียนโค้ดสวยสะอาด หรือ ขจัดโค้ดขยะก้อนใหญ่ทิ้งไปได้

ได้ประกาศให้ทุกคนรู้ถึงสิ่งที่จะทำให้สำเร็จ (public commitment) - ผมเก็บรายละเอียดไม่ทัน เดาว่าเป็นเรื่องของความโปร่งใส

เป็นคนที่ได้รับความไว้วางใจ 

ได้ทำความเข้าใจกับคำติชมอย่างลึกซึ้ง - Kent บอกว่าเวลาได้ feedback เขาจะอ่านคำชมผ่านๆแต่จะอ่านคำติหลายๆรอบและพยายามจะเข้าใจกับมันว่าอะไรทำให้เขาติเช่นนั้น จะพยายามไม่โกรธโดยเวลาคนอื่นว่าในสิ่งที่เขาไม่ได้เป็น

ได้ผันตัวเองเป็นคนที่เพิ่งเริ่มทำ - เมื่อไม่นานนี้ เขาได้มีโอกาสไปเป็นนักเรียนหัดเขียนภาษา Haskel ซึ่งทำให้เขาได้เห็นมุมมองใหม่และได้รับ feedback ที่ชัดเจนขึ้น 

นั่งสมาธิตอนเช้า - ช่วยทำให้ลูกตุ้มของเขาไม่เหวี่ยงไปยาวไป ตรงนี่ละมั้งที่ทำให้ผมเริ่มรู้สึกว่าเหมือนฟังธรรม

ได้ช่วยคนอื่นโดยไม่หวังผลตอบแทน - ตรงนี่เขาพูดถึงงานช่วยเหลือสังคมที่เขาทำอยู่

ทั้งหมดที่ Kent พูดนั้นผมมองว่าเป็นเรื่ิองของพยายามเข้าใจตัวเองและจัดการกับมันทั้งนั้น ลูกตุ้มที่ Kent บอกว่าเขาพยายามไม่ให้มันแกว่งยาวไปจากด้านดีสุดไปแย่สุด พอมานึกๆดูก็นึกไปถึงที่ อ.วรภัทร มักจะบอกว่าการมีสมาธิคือความสามารถในการคุมจิตไม่ให้เหวีี่ยงไปตามความคิดจรที่วิ่งเข้ามา และสติคือความสามารถในการมองเห็นการเหวี่ยงของลูกตุ้มนี้ นอกจาก Kent จะเคยบอกผมตอนที่ได้มีโอกาสคุยกันแป๊บนึงว่าเขาชอบอาหารไทยแล้ว Kent ยังเป็น speaker คนเดียวที่ผมเห็นว่าเขาไหว้คนฟังก่อนลงจากเวทีด้วย ผมเดาว่าเขาน่าจะศึกษาพุทธปัญญามาระดับนึง

Kent หักมุมกลับมาทิ้งท้ายว่า

วันหนึ่งมีพายุพัดมาที่ไร่ของชาวนา ทำให้ชาวไร่ต้องนาต้องรีบไปหาผู้ช่วยหนุ่ม

ชาวไร่บอกผู้ช่วยหนุ่มว่าต้องรีบเก็บฟางเข้าโรงนาไม่งั้นจะเปียกหมด ผู้ช่วยบอกจัดไปแล้วเรียบร้อย

ชาวไร่บอกผู้ช่วยหนุ่มว่าต้องรีบปิดหน้าต่างโรงนา ผู้ช่วยบอกจัดไปแล้วเรียบร้อย

ชาวไร่บอกผู้ช่วยหนุ่มว่าต้องรีบเอาสัตว์เข้าคอก ผู้ช่วยบอกจัดไปแล้วเรียบร้อย