ขอแค่ Sprint นี้ดีขึ้นนิดนึง ก็มากพอที่จะไปฉลองกันได้แล้ว
ผมเขียนเรื่องนี้ทิ้งไว้นานแล้วแต่ติดโน่นติดนี่ ไม่ได้เขียนจนจบซักที (ข้ออ้างล้วนๆ 555) วันนี้เขียนจบละ ลองอ่านกันดูครับ
ผมมีโอกาสได้ฟังจั๊วะ Chokchai Phatharamalai แชร์แนวคิดและประสบการณ์การเป็น ScrumMaster และ Agile Coach อยู่บ่อยๆ ซึ่งมีอยู่ 2 เรื่องที่ผมจำได้แบบขึ้นใจ ก็คือเรื่อง The Circle of Influence หรือ Circle of Zorro กับเรื่องที่จั๊วะคุยกับ Bas Vodde แล้วเข้าใจถึง … อ่า … จั๊วะใช้คำว่า กะลาของตัวเอง
แต่ถึงแม้ว่าผมจะอินกับ 2 เรื่องนี้มากแค่ไหน แต่ในเวลาที่ผมสวมหมวก Scrum Master และอยู่กับทีม ผมกลับไม่ค่อยหยิบมันมาใช้แบบจริงจังเลย จนกระทั่ง Sprint ที่ผ่านมาไม่นานนี่เอง ผมพบว่า เออ ที่จริงเราไม่ต้องหวังเป้าไกลไปก็ได้นะ เอาแค่เรื่องใกล้ๆ ตัวให้รอดก่อนไหม
เดี๋ยวผมจะกลับมาเล่าสิ่งที่ผมเจอนะครับ ผมขอเล่าเรื่องที่จั๊วะแชร์ให้ฟังก่อนละกัน
The Circle of Zorro (Influence)
เรื่องแรกจั๊วะเล่าให้ฟังตอน ODDS Gathering ครั้งที่ 2 ประมาณว่า ในหนังตอนแรกพระเอกไม่เก่ง แต่เป็นคนที่มุ่งมั่นอยากขจัดคนพาลเลยลุกขึ้นสู้ แต่ปรากฏว่าตัวเองสู้ยังไงก็แพ้และไม่สามารถเปลี่ยนแปลงอะไรได้เลย ก็เลยผิดหวังกินเหล้าเละเทะ จนอาจารย์มาพบเข้าและเห็นว่ามีแวว เลยพาไปฝึกในถ้ำ โดยวิธีการฝึกของอาจารย์ก็คือ เค้าจะขีดวงกลมไว้ 1 วงที่พื้น ซึ่งวงกลมนั้นไม่ใหญ่ไปกว่าปลายดาบของ Zorro จะยื่นไปถึง และให้ Zorro เข้าไปอยู่ในวงกลมนั้น จากนั้นก็บอกว่า วงกลมนี้เป็นทุกอย่างของ Zorro ให้ปกป้องวงกลมนี้เอาไว้ และห้ามออกมาเด็ดขาด โดยอาจารย์จะโจมดีเข้าไปและ Zorro ต้องป้องกันอย่างเดียว เมื่อไหร่ที่ Zorro ทำได้ดีแล้ว อาจารย์จะขยายวงกลมให้ ซึ่ง Zorro ก็สามารถเรียนรู้ที่จะอยู่ในวงกลมนั้น เมื่อผ่านไปได้ วงกลมก็ใหญ่ขึ้น จากวงเล็กๆ เป็นวงที่เดินได้ 3–4 ก้าว ขยายเป็นห้องในถ้ำ ขยายเป็นโถงที่ใหญ่ขึ้น และสุดท้ายก็คลุมทั้งถ้ำ … Zorro จึงถือกำเนิดขึ้นมาอย่างที่เรารู้กัน
วงกลมของ Zorro คือ Circle of Influence โดยที่เมื่อเทียบกับ ScrumMaster มือใหม่แบบผมแล้ว เวลาที่ได้รับมอบหมายให้เข้าไป groom ทีม ผมก็มักจะคิดไปไกลชนิดที่ว่าตัวเองยังไม่รู้เลยว่าจะทำอะไรได้แค่ไหน มีข้อจำกัดอะไร แต่เริ่มคาดหวังไปละ พอทำไม่ได้ความรู้สึกผิดและท้อแท้ก็จะกลับมาทำร้ายตัวเราเอง
ซึ่งจริงๆ แล้วถ้าเราตีกรอบให้เล็กๆ หน่อย ดูสิ่งที่อยู่ตรงหน้าว่าเราพอจะทำอะไรได้บ้าง แล้วค่อยๆ ทำในสิ่งที่เราพอทำได้ การแก้ปัญหาหรือการทำให้คนใกล้ตัวเข้าใจ (influence) จะง่ายกว่ามาก ถึงแม้ว่าปัญหาที่แก้ได้อาจจะไม่ได้ทำให้เปลี่ยนทีมจากหน้ามือเป็นหลังมือ แต่อย่างน้อยก็ยังดีกว่ามัวแต่หวังสูงแต่ ไม่ทำอะไรไม่ได้ซักอย่าง
Win Small, but Often
อีกเรื่องเป็นเรื่อง จั๊วะเล่าตอนตอบคำถามใน class Introduction to Scrum ที่จัดให้ลูกค้า จั๊วะเล่าว่า ครั้งหนึ่งเคยพูดกับ Bas ว่า “งานของ consult (หรือ Agile Coach จำไม่ได้ละ) นี่น่าสงสารนะ” Bas ถามว่า “ทำไมยูคิดอย่างนั้น?” จั๊วะบอกว่า “อ้าว ก็เวลาลูกค้าจ้างเข้าไป มักจะมีระยะเวลา เช่น อาจจะ 6 เดือน หรือ 1 ปี พอทีมทำท่าจะดีก็หมดสัญญา ต้องไปเริ่มนับหนึ่งใหม่กับทีมใหม่ แบบนี้ก็ไม่มีโอกาสสร้างทีมที่สุดยอดได้ซักที” … Bas เงียบไปนิดนึง แล้วตอบกลับมาว่า
“ไอไม่รู้หรอกนะว่าทีมที่สุดยอดในความหมายของยูเป็นยังไง แต่ทุกวันที่ไออยู่กับทีม ขอแค่มีเรื่องอะไรเล็กๆ ที่ทีมได้เรียนรู้หรือพัฒนา มันก็มากพอที่จะฉลองได้ทุกวันแล้ว”
จั๊วะบอกว่า ณ เวลานั้นรู้สึกทันทีเลยว่า ตัวเองเหมือนกบในกะลาที่ Bas เปิดกะลาให้เห็นโลกกว้าง (… กูด้วยยย) แน่นอนว่า Bas เป็น Agile Coach ระดับโลก ไปโค้ชให้บริษัทต่างๆ มาแล้วมากมาย ต้องเคยเห็นทีมที่เก่งมากๆ มาแล้วแน่ๆ แต่บาสก็ยังคง focus อยู่กับทีมที่อยู่ตรงหน้าเพื่อโค้ชให้ทีมนั้นเก่งขึ้นทุกวันโดยไม่เปรียบเทียบเลย ทำให้ทีมรู้สึกภูมิใจในตัวเองได้ทุกวัน โดยไม่จำเป็นต้องคาดหวังหรือเคี่ยวเข็ญทีมนั้นว่าจะต้องเป็นแบบโน้นแบบนี้เลย
My Story
2 เรื่องนี้มีคุณค่ากับผมมาก แต่อย่างที่บอกไปครับว่า ที่ผ่านมาผมไม่ค่อยได้ตั้งใจว่าจะเอาไปใช้ในงานจริงๆ เลย จนถึง Sprint Review หลังๆ ไม่นานมานี้เอง
ช่วงหลังๆ นี้ผมมีโอกาสไปเป็น Agile Coach ที่ต้องดูแลทีมพร้อมๆ กันหลายทีม ในวันปิด Sprint นึงของทีมเหล่านั้น ผมเจอจังหวะที่ทำให้นึกถึง 2 เรื่องนี้ขึ้นมา เลยถือโอกาสลองเปลี่ยนวิธีทำงานของเค้าครับ
ก่อนที่ผมจะได้ทำงานกับทีมนี้ ด้วยเงื่อนไขหลายๆ อย่าง (ขอสงวนสิทธิ์ไม่ลงรายละเอียดว่าเพราะอะไร) ที่ผ่านมาทีมไม่เคยมีการเอา software มา review กันใน Sprint Review เลย การ review ที่เค้าทำกันมา คือ นั่ง update status งาน ของแต่ละคนกับ PO แค่นั้น มีการกำหนดระยะเวลาของ Sprint คือ Sprint ละ 2 weeks ก็จริง แต่ทีมก็ไม่ได้รู้สึกถึงความสำคัญเลย งานไม่เสร็จก็ไม่เป็นไร แค่ยกยอดไปทำต่อ Sprint หน้า สุดท้ายใน sprint ก็มีแต่ undone work ที่ลากยาวไปเรื่อยๆ บอกไม่ได้ว่าเสร็จเมื่อไหร่ รวมถึงทีมใช้ Jira เป็น Sprint Backlog เวลาเข้าไป update status ของ task ก็ชอบ filter ดูเฉพาะงานตัวเอง ทำให้ทีมแทบไม่ช่วยกันแก้ไขปัญหาของงานที่มี priority สูงกว่าเลย สนใจแค่งานตัวเองเท่านั้น
ก่อนหน้านี้ผมมีแนวทางที่ผมคิดเอาไว้แบบนึง แล้วผมก็พบว่าแนวทางนั้นมันเกินตัวไปมาก ไม่มีทางที่จะทำได้ด้วยตัวคนเดียว เผลอๆ อาจจะเป็นไปไม่ได้เลยด้วยซ้ำ แล้วจู่ๆ ผมก็นึกถึงเรื่อง Circle of Influence ที่จั๊วะเล่าให้ฟังขึ้นมา ก็เลยกลับมาคิดว่าเราทำอะไรได้บ้างนะ อะไรที่เล็กๆ แต่น่าจะทำให้ทีมเห็นปัญหาชัดขึ้น Sprint ที่ผ่านมาผมก็ขออนุญาติ PO และทีมว่า จะขอปรับการทำงานจากที่เคยทำมา คือ ขอลองให้ทีมมี collaboration กับ focus มากขึ้น PO ก็เอาด้วยครับ สิ่งที่ผมขอทีมคือ
- อย่างแรก เนื่องจากทีมต้องใช้ Jira และรู้สึกเสียเวลากับการลง task มาก ผมจึงเสนอไอเดียว่า งั้นเรามาลองใช้ physical board ไหม ทำ column แบบใน Jira เลย ส่วน Jira ใส่เฉพาะ backlog items ก็พอ ไม่ต้องลงระดับ task (management เค้าไม่สนใจ task ย่อยๆ อยู่แล้ว เค้าสน Story Point กับ Burn-down เท่านั้น) ทีมประเมินว่า มันก็แย่หน่อยตรงที่ต้อง update 2 ที่ แต่ถ้ามีแค่ backlog items มันก็เหลือแค่ไม่กี่ใบเอง ก็เลยขอลองทำก่อน 1 Sprint เดี๋ยวมาว่ากันใหม่ถ้าไม่ OK
- ทีมมักจะเอางานเข้า Sprint เยอะ (ก็โดน pressure มาเป็นทอดๆ เป็นปกติ) พอถึงกลาง Sprint ผมก็เลยถามทีมไปว่า อยากคุยกับ PO ไหม เพราะผมเห็นว่าทีมไม่น่าจะ delivery ได้หมด พอได้คุยกัน PO ก็เข้าใจและยอมให้ทีมคืน backlog item ที่มั่นใจว่าไม่ได้ทำแน่ๆ กลับไป ทีมก็ focus มากขึ้นกับงานที่ลดลง
- Sprint นี้ผมย้ำกับทีมว่า จะมากหรือน้อยยังไงก็แล้วแต่ ยังไงก็ต้องเอา software ที่เสร็จแล้วมา run ให้ PO ดูให้ได้ ทีมก็ตอบตกลงแบบไม่ได้คิดอะไร (อาจจะคิดก็ได้นะ ว่าทำไมผมต้องเน้นเรื่อง review จัง แต่ก็ไม่ได้งอแงอะไร)
เมื่อถึงเวลา Sprint Review ทีมก็ตกลงกันว่าให้คนที่ลงมือทำส่วนนั้นๆ เป็นคนเล่น feature นั้นให้ PO ดู ซึ่งระหว่างทางก็มีบลั๊ฟกันตลอดว่า “ไม่มี bug จริงเร้อ”, “อะไรนะ? ทั้ง sprint ได้แค่นี้” บรรยากาศก็จะเฮฮาหน่อย เพราะที่ผ่านมาไม่เคยได้เห็นงานของเพื่อนเลย เมื่อจบ review PO ก็บอกผมว่า วันนี้รู้สึกดีมาก เพราะที่ผ่านมาไม่เคยเห็นเลยว่าทีมรู้สึกกับงานของตัวเองยังไง วันนี้ได้เห็นชัดๆ ว่าทีมภูมิใจนำเสนองานมาก รู้สึกได้เลยว่ามันเหมือนกับ Small Achievement และรู้สึกว่าจบงานตาม Sprint จริงๆ (ดึงอันที่มั่นใจว่าไม่เสร็จออก)
ตอนนี้เองที่ผมนึกถึงเรื่องเล่าของจั๊วะที่คุยกับ BAS และพบว่า เออ มันก็แค่นี้เองนี่หว่า ไม่เห็นต้องทำอะไรใหญ่โตเลย เอาแค่ step เล็กๆ ก่อนก็ได้นี่ ให้ทีมได้รู้สึกว่างานเสร็จ ได้โชว์ผลงาน ได้สนุกกับการ review ด้วยกัน ส่วน PO ก็ได้เห็นสิ่งที่ตัวเองอยากได้ และได้เห็นความภูมิใจในงานจากสมาชิกในทีม รับรู้ถึงความตั้งใจของทีม เราเพิ่งเดินกันมาไม่นานเอง ได้แค่นี้ก็ถือว่าก้าวหน้าแล้วนะ
Keep Next Small Win!
พอได้แนวทาง ผมก็อยากลองต่อไป ซึ่งเย็นนั้นก่อนกลับบ้าน ผมก็ชวนทำ Retrospective ที่ผ่านมาผมมักจะพาทำ reto ด้วยท่าโน้นบ้าง ท่านี้บ้าง แต่คำถามที่ผมถามทีมในช่วง Bad (จาก Good, Bad, Try) มักจะถามประมาณว่า …
“มีเรื่องอะไรที่ทีมคิดว่ายังทำได้ดีกว่านี้ หรือถ้าไม่มีปัญหานี้จะทำให้การทำงานดีขึ้น?”
ซึ่งหลายๆ ครั้งทีมมักได้ของที่ปรับปรุงได้ยาก หรือเป็นปัญหาที่เป็นข้อจำกัดจริงๆ แก้ไม่ได้ แต่ทีมรู้สึกแย่กับมัน แล้วก็รู้สึกว่า retro ทำไมนะ ไม่เห็นจะมีอะไรดีเลย เย็นวันนั้นผมก็เลยลองถามใหม่ว่า …
“ใน Sprint ที่ผ่านมามีเรื่องอะไรที่พวกเราคิดว่ายังทำมันได้ดีกว่านี้ไหม โดยที่เรื่องนั้นไม่ต้องเป็นเรื่องใหญ่โตนะ ให้ลองมองหาปัญหาเล็กๆ ที่แก้ได้ไม่ยาก และลงมือทำได้ใน sprint หน้าเลย?”
ผมพบว่า ปัญหาที่ทีมแชร์ มักจะเป็นปัญหาที่ทีมหา solution มาทำเองได้จริงๆ เช่น มาทำ code review กัน, ลอง stand up เช้า-เย็น, จบ 1 Baclkog เบรค 1 ชั่วโมง, และอื่นๆ อีกมากมาย แน่นอนว่ามันอาจจะไร้สาระในสายตาของคนนอก แต่การได้ทำอะไรเล็กๆ และสำเร็จบ่อยๆ กลับสร้างกำลังใจและความเป็นทีมอย่างไม่น่าเชื่อ บรรยากาศการทำงานก็เริ่มเปลี่ยนไป
Conclusion
มาถึงตรงนี้ ผมเองก็ได้เรียนรู้เช่นกันว่าความสำเร็จเล็กๆ แต่เกิดบ่อยๆ นั้นสร้างกำลังใจได้มหาศาล ซึ่งการจะทำอย่างนั้นได้เราก็แค่มองไปรอบตัวใกล้ๆ ว่ามีอะไรไหมที่เราพอจะทำได้ แทนที่จะไปมัวเสียเวลากับปัญหาที่ไกลเกินมือเอื้อมหรือใหญ่เกินตัวที่ไม่รู้ว่าจะแก้ได้ยังไง พอปัญหาเล็กๆ รอบๆ ตัวเริ่มหมดไป เดี๋ยวค่อยดูกันต่อว่ามีอันไหนนะที่เราพอจะทำได้ก็ค่อยว่ากัน
ก็หวังว่าจะได้ประโยชน์กันไม่มากก็น้อยนะครับ ขอให้สนุกกับการทำงานครับ ^^
