My #AgileSG16 Day 1 — Morning : Mary Poppendieck, Sociocracy, LeSS & Satir

งาน Agile Singapore 2016 ซึ่งงานสัมมนาอไจล์งานใหญ่ที่สุดของภูมิภาค ปีนี้มีคนไทยมาร่วมงานเกือบ 20 คน ซึ่งนับว่ามากกว่าทุกๆปีที่ผ่านมา ผมโชคดีที่ได้รับบัตรเชิญจากทางงานในฐานะตัวแทน community จากเมืองไทย คิดว่าคงจะได้นำประสบการณ์กลับไปปรับใช้ทั้งในฐานะโค้ชและในฐานะคนจัดงาน เขียนไปเขียนมาแล้วชักยาว ขอแบ่งเป็นทีละครึ่งวันละกันนะครับ

The Future has Arrived
Mary Poppendieck

หัวข้อแรกเปิดตัวด้วย keynote จาก Mary Poppendieck ผู้บุกเบิกการเอา Lean มาใช้ในขบวนการพัฒนาซอฟต์แวร์คนแรกๆของวงการ ผมก็ติดตามงานเขียนของแกมานาน ได้มาเจอตัวจริงก็ยิ่งปลื้มเลย

Mary พูดถึงอนาคตของวงการซอฟต์แวร์ 7 หัวข้อ ที่เกิดขึ้นแล้วในหลายๆที่ แต่เราจะยังไม่เป็นที่รู้จักในวงกว้าง

  1. Scaling Out over Scaling Up สมัยก่อนตอนเราจำเป็นต้อง scale เรามักเพิ่มขนาดของ server ให้ใหญ่ขึ้น หรือ Scale Up แต่การ scale แบบนี้ไม่เพียงพอที่จะรับความต้องการในปัจจุบันอีกต่อไปแล้ว เราจำเป็นต้อง scale โดยปรับ architecture ให้สามารถเพิ่มจำนวน server ให้มากขึ้น หรือ Scale Out (อย่างพวก AWS) ป้ายังไม่วายแขวะพวก Scaling Agile ทั้งหลายว่าก่อนจะ scale เรื่อง process ควรมาดูเรื่อง architecture ก่อน
  2. Infrastructure as Code ป้าบอกว่าอีกหน่อย infrastructure จะเหมือนไฟฟ้า ที่เราซื้อบริการจากการไฟฟ้า พูดถึง Docker, Lamda และ Software-Defined Network (SDN) ประมาณว่ามันมาอยู่บนซอฟต์แวร์หมดละ
  3. API as Integration แต่ก่อนเรามี database ก้อนใหญ่ก้อนเดียว จะแก้อะไรทีก็กระทบไปหมดทุกอย่าง ทางเดียวที่จะ scale ได้คือต้องมี federated architecture และคุยกันผ่าน API เช่นพวก Micro Services
  4. Fault Injection เราต้อง code ด้วยสมมุติฐานว่าอะไรๆก็พังได้ แต่ไม่ใช่ว่าจะมาพยายามให้มี up time กัน 99.99% ซึ่งได้ไม่คุ้มเสีย ควรเน้นทีว่าทำยังไงให้เจ๊งแล้วกลับมาได้เร็ว
  5. Team Insight หมดสมัยแล้วที่ทีมจะมานั่งทำตามคำสั่งที่ใครสักคนคิดมาให้ ช้าไม่ทันกิน มันต้องมาช่วยกันคิด เพราะหลายหัวย่อมดีกว่าหัวเดียว (collective wisdom outweighs individual’s insight) เครืองมือที่ช่วยก็เช่น Proven Design Process หรือ Design Sprint
  6. Digitization ถ้าไม่กระโดดมาร่วมวง digital ก็เตรียมยกตลาดให้คู่แข่งไปได้เลย เดี๋ยวนี้ต้อง Digital To The Core ไม่ว่าจะเป็น รถยนต์ไร้คนขับ ไม้เทนนิสที่ฝังเซนเซอร์เก็บข้อมูลการตีไว้วิเคราะห์ เอา Deep Learning มาช่วยคัดแตงกวา ฯลฯ
  7. Platforms เช่น AirBnB หรือ Uber ขาย “พื้นที่” ให้ผู้ซื้อพบผู้ขาย และ Platform จะชนะ Product เสมอเพราะถ้ามันเวิร์คแล้วมันขยายได้โดยไม่ต้องเพิ่มต้นทุน

ทุกสไลด์ของป้า Mary มีประโยคว่า Software is Eating The World อยู่ด้านล่าง! ใครที่ยังไม่เข้าใจประโยคนี้ผมแนะนำให้ลองไปอ่านบทความบน Wall Street Journal ของ Marc Andreessen ที่เขียนไว้ตั้งแต่ปี 2011 เรื่อง Why Software Is Eating The World นะครับ

ป้า Mary แม้จะอายุมากแล้วแต่พลังล้นเหลือจริงๆ สุดยอดครับ

Sociocracy — A means for true agile organizations
Jutta Eckstein

Jutta บอกว่าปัจจุบันเวลาจะทำอไจล์เรามักจะติดกันเรื่อง Buy-In เรื่องการตัดสินใจที่ไม่โปร่งใส และ Hierachy ซึ่ง Sociocracy ซึ่งเป็นเป็นวิธีการบริหารที่กระจายอำนาจไปสู่คนทำงานหรือ self-managing organization ช่วยเรื่องนี้ได้

Jutta พูดถึงหลักการบางข้อเข่น

การตัดสินใจด้วยความยินยอม (consent decision)

บางทีการใช้ dotted vote ก็ทำให้เรื่องที่ได้รับโหวตน้อยไม่ได้รับความสนใจ หรือจะใช้วิธีหาเสียงเอกฉันท์ก็ต้องใช้เวลามาก แต่ในความเป็นจริงแล้ว ไม่มีใครรู้หรอกว่าที่เรากำลังตัดสินใจกันอยู่นั้นผลจะออกมาเป็นอย่างไร

แทนที่จะมัวพะวงหาการตัดสินที่ดีที่สุด จะดีกว่าไหมถ้าเราจะหยุดอยู่แค่การตัดสินใจที่ดีพอ เราอาจจะคุยกันว่าข้อผิดพลาดที่อาจจะเกิดขึ้นจากการตัดสินใจนี้เรารับได้ไหม มีใครมีความเห็นคัดค้านแบบหัวชนฝา(paramount objections) ไหม ถ้าไม่มีก็จบ หรืออาจจะใช้วิธีแปะวันหมดอายุว่าการตัดสินใจนี้มีผลถึงเมื่อไหร่ เมื่อถึงเวลาแล้วเราก็มาทบทวนกันอีกทีว่าเอาไงต่อ

การเลือกตั้งด้วยความยินยอม (elections by consent)

เคยสงสัยไหมว่าคนนั้นคนนี้ในองค์กรได้รับมอบหมายหน้าที่นั้นๆมาได้ยังไง หลายครั้งเราก็ไม่ได้คิดว่ามันเหมาะสมสักเท่าไหร่

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

double-linking

โดยปกติแล้ว การตัดสินใจในองค์กรจะเป็นไปตามสายบังคับบัญชา (hierarchy) จากบนลงล่าง (top-down) แต่หลักการ double-link คือการเพิ่มตัวแทนจากระดับล่างให้ไปมีส่วนร่วมกับการตัดสินใจกับทีมของผู้บริหารในระดับที่สูงขึ้นไปหนึ่งระดับด้วย เป็นขั้นๆขึ้นไปจากล่างขึ้นบน (bottom-up) การเชื่อมโยงของระดับการตัดสินใจจึงเกิดขึ้นทั้งสองทาง

Jutta ให้ความเห็นว่า หลายๆครั้ง Scrum Master มักจะประสบปัญหาไม่มีส่วนร่วมในการตัดสินใจต่างๆขององค์กรที่มีผลกระทบกับทีม การให้ Scrum Master เป็นตัวแทนของทีมขึ้นไปมีส่วนร่วมตัดสินใจกับผู้บริหารในระดับที่สูงขึ้นไปตาม double linking จึงเป็นทางออกทางหนึ่ง

หลักการเหล่านี้สามารถนำไปใช้กับการทำงานปัจจุบันได้เลยโดยไม่ต้องปรับอะไรมากในองค์กร

ป.ล. อีกวันหนึ่งพอดีไปนั่งข้างๆ Jutta เลยถามแกว่า Sociocracy นี่ดูจะเป็นเรื่องเดียวกันกับ Holacracy และ Teal Organization เลย แกบอกว่าใช่แต่อันอื่นดูจะมีอะไรใส่ไปเพิ่มเยอะ แกชอบอันนี้ เรียบง่ายดี สนใจเพิ่มเติม ไปดูกันต่อที่ sociocracy.com ได้นะครับ

Story of LeSS
Bas Vodde

“พ่อๆ อยากไปเร็วๆ” นิค ลูกชายวัย 3 ขวบ บ่นกับบาสผู้เป็นพ่อขณะรถติดว่า 
พ่อก็ตอบว่า “เร็วกว่านี้ไม่ได้หรอก ก็รถมันติด” พ่อบาสตอบ
นิคมองไปยังเลนฝั่งที่วิ่งสวนกันมาแล้วบอกว่า “ฝังโน้น ยังไปได้เร็วเลย”

“แต่มันไปผิดทางนะลูก ถ้าให้เลือกระหว่างไปช้าๆแต่ถูกทาง แต่ไปเร็วๆแต่ผิดทาง ลูกอยากจะไปทางไหน” พ่อถาม
“ไปเร็วๆ!” นิคตอบทันควันอย่างไม่ต้องคิด

บาสบอกว่าวันนั้นก็ฟังขำๆ แต่ผ่านไปสองสามวันก็มาคิดได้ว่า องค์กรส่วนใหญ่ในโลกเรานี้ มักจะหมกมุ่นกับการไปเร็วๆแต่ผิดทาง

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

บาสเล่าย้อนไปถึงต้นกำเนิดของ LeSS สมัยตั้งแต่ยังไม่มีชื่อเรียกเก๋ๆแบบนี้ว่ามันเริ่มตั้งแต่เขาช่วย Nokia Network ทำทีม 20 ทีม โดยโจทย์ตอนนั้นคือจะทำ Scrum อย่างไรกับทีมหลายๆทีม ซึ่งบาสย้ำว่ามันคนละเรื่องกันกับการทำให้ทีม Scrum หลายๆทีมมาทำงานร่วมกัน

บาสบอกว่าตอนนั้นอ่านตำรามาหมดละ มาโดนกับงานของ Microsoft ในยุคแรกๆ ในยุคที่ Microsoft ยังเป็นผู้นำในการทำซอฟต์แวร์ของโลก เป็นงานเขียนของหัวหน้าทีม Excel และหัวหน้าทีม VC++ (Jim McCarty) ซึ่งเป็นแรงบันดาลใจให้กับหัวใจหลักอันหนึ่งของ LeSS นั่นก็คือเรื่อง Feature Team

การจัดโครงสร้างองค์กรให้เป็น Feature Team จะช่วยขจัด dependency ระหว่างทีมไปได้ บาสเคยนึกว่า dependency ทั้งหลายนั้นเป็นตัวปัญหาแต่ตัวปัญหาจริงๆนั้นอยู่ที่ asynchronous dependency หรือการที่ทีมต้องรอคำตอบอะไรบางอย่างจากอีกทีมหนึ่ง ในขณะที่ synchronous dependency คือ dependency ที่ต้องการคำตอบทันทีเช่น merge conflict กลับเป็นเรื่องที่ดีเพราะทำให้เกิด collaboration และเทคโนโลยีในปัจจุบันเช่นพวก distributed version control และ continuous integration ทำให้เรื่องเหล่านี้เป็นเรื่องไม่ยากอีกต่อไป

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

LeSS นั้นมี principles อยู่หลายข้อแต่บาสจะขอยกมาข้อเดียวคือ More with LeSS หรือขยายความต่ออีกหน่อยคือ Build Your Method Up. Don’t Tailer It Down. ต้องให้องค์กรเห็นปัญหาเองและแก้ปัญหาโดยค่อยๆใส่ process หรือ role เข้าไปเพิ่มเท่าที่จำเป็น ไม่ใช่ใส่เข้าไปเต็มไปหมดตั้งแต่แรก

จุดนี้ผมเข้าใจว่าเป็นจุดหลักที่บาสไม่เห็นด้วยกับ SAFe ผมเห็นด้วยกับบาสในเรื่อง Build Up แต่ผมไม่เห็นด้วยทั้งหมดในเรื่องที่มองว่า SAFe เป็น Tailer Down อาจจะเป็นเพราะประสบการณ์ที่ผ่านมาของผมกับ SAFe นั้นก็เป็น Build Up! เพียงแต่ส่ิงที่เอามาเติมนั้นผมก็ดูในกล่องเครื่องมือของ SAFe ก่อน แต่นั่นก็ขอเก็บไว้ว่ากันวันหลัง ;-)

บาสตบท้ายไว้ว่า ยิ่งมี artifacts ที่ต้องทำเยอะ ยิ่งจะทำให้ได้ร่วมมือกับลูกค้าน้อย ยิ่งมี process เยอะ ยิ่งทำให้คนมี ownership น้อย

How Collaboration Works or Doesn’t
Becky Winant

คุณ Becky พูดเรื่อง Satir ล้วนๆเลย เห็นแล้วก็รู้สึกดีที่คนในแวดวงไอทีระดับโลก เริ่มเข้ามาสนใจเรื่องโลกภายในของคนเรากันมากขึ้น

Becky เล่าเรื่อง Satir Interaction Model ว่าเวลาเรารับสารอะไรเข้ามา สารนั้นจะวิ่งผ่านขบวนการ 4 ขั้นตอนในหัวเราคือ

  1. Intake เมื่อกี้ฉันได้รับรู้อะไรมานะ
  2. Meaning มันหมายความว่าอะไรนะ
  3. Significant แล้วฉันรู้สึกอย่างไรกับมัน โอไหม
  4. Response ฉันมีกฎอย่างไรกับเรื่องนี้บ้าง

ลองคิดดูว่าคนเราแต่ละคนมี processor unit 4 ขั้นในตัวเราแต่ละคน ซึ่งแต่ละคนจะ process ไม่เหมือนกันเลย เพราะว่า build มาไม่เหมือนกัน ก็ไม่แปลกอะไรทีเราจะทะเลาะกันในเรื่องไม่เป็นเรื่องบ่อยๆ โดยเราก็มักจะลืมกันไปว่าคนเรานั้นต่างกัน

Becky แนะว่าให้ ปล่อยวางคำตัดสิน อย่าเพิ่งด่วนสรุป โดยวิธีการที่อาจจะพอช่วยได้ก็มี

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

สตินะครับสติ

จบสรุปครึ่งวันแรกละ โปรดติดตามตอนต่อไป ขอรวบรวมพลังก่อน ฮีบๆ

งานบ้านเขาจบไปแล้ว อย่าลืมงานบ้านเรา Agile Tour Bankok 2016 นะครับ วันที่ 28–29 ต.ค. นี้ ที่ รร มณเฑียรริเวอร์ไซด์ บัตรราคาถูกกว่า Agile Singapore 5 เท่า มี keynote ระดับโลก, speaker ทั้งไทยเทศหลากหลาย, workshop เด็ดๆมากมาย, open space ให้คุณได้แบ่งปัน, มีวงสุนทรียสนทนาอไจล์ และที่สำคัญ อาหารเราอร่อยกว่าแน่นอน ลองมาแล้ว บัตรจำหน่ายที่ agiletourbkk.org นะครับ

Like what you read? Give Kulawat Pom Wongsaroj a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.