สวัสดีค่ำคืนวันเสาร์ที่ 9 เมษายน พ.ศ. 2559 ก้าวเข้าสู่เดือนเมษายน เดือนที่ร้อนตับแลบ แลบ และแลบ อากาศร้อน แต่ใจอย่าร้อนเน้อเพื่อนพ้องน้องพี่ ค่ำคืนนี้หยิบบทความจาก Blog ของ Crisp ที่ผมได้เจอเมื่อสัปดาห์นี้ซึ่งชอบมากๆ เลยตามไปหาเจ้าของบทความนี้ว่าขอแปลเป็นภาษาไทยได้ไหม เจ้าของบทความตอบมาว่า “จัดไป” ก็เลยจัดการแปลบทความชื่อ 12 seemingly normal things Agile people do เขียนโดย Mattias Skarin (Kanban, Lean and Agile mysteries ณ Crisp) ซึ่งส่วนของการแปลเป็นภาษาไทยนั้นจะมีองค์ประกอบสองส่วนคือ เนื้อหาจากบทความของ 12 seemingly normal things Agile people do ผสมกับประสบการณ์ส่วนตัวของผมเองลงไปนะจ๊ะ

หลายต่อหลายครั้งผมมักจะได้ยินคำพูดว่า “นี่ยังไม่แอจไจล์” ซึ่งส่วนตัวผมเองเคยเขียนบทความตอน ยังไม่ แอจไจล์!!! พ่อง!!! ไว้ใน SCRUM123 นี้ไว้ จนเช้าวันอังคารที่ 5 เมษายน พ.ศ. 2559 ผมได้เจอบทความ 12 seemingly normal things Agile people do พอได้เสพก็ เออ!!! แบบนี้แหละที่บอกได้ว่าการทำงานแบบที่คล่องตัว ทำงานเป็นทีมเดียวกัน มันต้องเป็นแบบนี้ โดยในบทความนี้ได้พูดถึง 12 จริตที่เหล่าคนพัฒนาซอฟต์แวร์แบบแอจไจล์กระทำกันจนเป็นเรื่องปกติ ในการพัฒนา และส่งมอบซอฟต์แวร์ด้วยแอจไจล์ ซึ่งเอาจริงๆ ไม่ต้องแอจไจล์เราก็นำไปใช้งานได้นะจ๊ะ และส่วนตัวผมเชื่อว่าเราๆ ก็มีจริตเหล่านี้อยู่จะมากหรือน้อยเพียงใด ก็แล้วแต่ ซึ่งบทความ 12 seemingly normal things Agile people do ได้พูดถึง 12 จริตไว้ดังนี้

จริตที่ 1: พูดคุยกันบนกระดานไวท์บอร์ดเพื่อแก้ไขปัญหา

Agile-Behaviours-Whiteboard

เมื่อมีปัญหา แทนที่จะโวยวายโน้นนี่นั่น หรือมายืนคุยกันโดยใช้มโนบนอากาศ หรือเขียนอีเมลเพื่อสร้างสงครามโลกครั้งที่ 3 ก็จูงมือคนที่เกี่ยวข้องกับปัญหานั้นๆ มาคุยกันหน้ากระดานไวท์บอร์ด หรือกระดาน Flipchart หรือหยิบกระดาษ A4 แล้วก็ลงมือวาดภาพ วาด Diagram วาด Flow ของปัญหานั้นๆ ลงบนกระดาน หรือจะใช้เทคนิคแบบ Mindmapping หรือ Fish bone diagram เข้ามาช่วยก็ได้ เพื่อให้ทุกๆ คนที่เกี่ยวข้องกับปัญหานั้นเห็นภาพตรงกัน โครตจะง่ายเลยในการแก้ไขปัญหา มีเพียงปากกา กระดาษ หรือกระดานเท่านั้น ลองกันดูจ้า

จริตที่ 2: เสพกาแฟสักแก้ว ก่อนเริ่มต้นการพูดคุยเพื่อปรับปรุงเรื่องต่างๆ ให้ดีขึ้น

Agile-Behaviours-Coffee

เมื่อมีปัญหาเกิดขึ้น สิ่งที่ตามมาก็คือการแก้ไขปัญหานั้น แล้วก็กระทำการปรับปรุง และพัฒนาให้ดีขึ้นเพื่อที่ เราจะไม่ล้มที่เดิมอีก (ชอบประโยคนี้จากจั๊ว Chokchai Phatharamalai) แทนที่จะตั้งปัญหาตรงจุดโทษ แล้วก็ซอยเท้าวิ่งเข้าไปเตะตูมลอยเข้าไปทุ่งโกโก้ แล้วก็ระเบิดตูมลงกลางหัวของคน หรือทีมที่อาจจะ หรือจะ เป็นต้นสายปลายเหตุของปัญหานั้น เราลองค่อยๆ ดูว่าใครกันน้าที่จะเป็นคนที่จะสามารถพูดคุยเรื่องของปัญหาที่เกิดขึ้น พร้อมทั้งวางแผนเพื่อดำเนินการแก้ไขได้ เมื่อหาเจอแล้วก็ชวนเขาคนนั้นไปเสพกาแฟ หรือเครื่องดื่มแก้วโปรดของเขาคนนั้นที่ร้านกาแฟดู ส่วนตัวผมเคยใช้มาแล้วทั้งกับตัวบุคคล และทีม แล้วมันก็ได้ผลจริงๆ นะเออ

จริตที่ 3: แวะไปเยี่ยมเยียนทีมพัฒนาและส่งมอบซอฟต์แวร์ทุกๆ วัน

Agile-Behaviours-Walkaround

เพื่อให้เราสามารถที่จะรับรู้เรื่องราวต่างๆ ที่เกิดขึ้นได้ในแต่ละวันของการพัฒนาและส่งมอบซอฟต์แวร์ในฐานะของ  ScrumMaster หรือ Agile Coach หรือหัวหน้าทีม หรือผู้จัดการ ลองเริ่มต้นวันด้วยการเดินไปแวะเยี่ยม ทักทาย ทีมพัฒนาและส่งมอบซอฟต์แวร์แต่ละทีมทุกๆ แล้วก็ลองถามไถ่ถึงสิ่งที่จะทำกันในวันนี้ ปัญหาที่เกิดที่เราสามารถช่วยเหลือได้ พร้อมทั้งสารทุกข์สุขดิบ ซึ่งใช้เวลาไม่มาก แต่เราก็สามารถรับรู้เรื่องราว และความเคลื่อนไหวต่างๆ ในแต่ละวันได้ของทุกๆ ทีม อีกทั้งยังได้มาเรื่องของความสัมพันธ์อันดีระหว่างเรา และสมาชิกของทีมพัฒนา และส่งมอบซอฟต์แวร์นะจ๊ะ

ส่วนตัวผมเอง Daily Scrum (ถ้าคุณใช้ Scrum) หรือ Daily Sync Up/Daily Meeting (ถ้าคุณทำงานเป็น Iteration) นั่นก็เป็นอีกหนึ่งพิธีกรรมที่ดีที่เราจะเข้าไปยืนฟัง เน้นว่า ไปยืนฟัง นะจ๊ะ

จริตที่ 4: จบประชุมด้วยคำถาม “เรามีอะไรที่ต้องสนใจและลงมือทำบ้างจ๊ะ”

Agile-Behaviours-Now-B

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

จริตที่ 5: จัดเวลาในแต่ละวันสำหรับทำอะไรที่ไม่ใช่งานแต่ช่วยในการทำงาน

Agile-Behaviours-Slack

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

จริตที่ 6: ปรับปรุงกระบวนการทำงาน ด้วยปากกา และกระดานไวท์บอร์ด

Agile-Behaviours-Improve-the-existing-process

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

เปลี่ยนใหม่ลองเริ่มต้นง่ายๆ ด้วยแบบนี้ เรียนเชิญสมาชิกทีมทั้งหมดไปที่กระดานไวท์บอร์ด หรือกระดาษ Flip Chart พร้อมกับทุกคนมีปากกา Marker หรือปากกาเมจิก และที่ขาดไม่ได้คือ Post-it 2 สี แล้วก็ดำเนินพิธีกรรมดังนี้

  • ให้สมาชิกของทีมช่วยกันเขียนกระบวนการทำงานปัจจุบันที่ทำๆ กันอยู่ลงบนกระดานไวท์บอร์ด หรือกระดาษ Flip Chart
  • ให้สมาชิกของทีมช่วยกันเขียนความท้าทายต่างๆ ในมุมมองของตนเอง เช่น แก้ไขคอขวดที่เกิดขึ้น ลงบน Post-it แล้วก็เอาไปแปะไว้ในแต่ละขั้นตอนของกระบวนการทำงานที่ถูกวาดออกมา
  • แล้วก็ให้แต่ละคนเสนอความคิด หรือแนวทางการปรับปรุงแก้ไขความท้าทายต่างๆ ที่เขียนแปะไว้ให้ดีขึ้น เช่นเดียวกันแนวคิด แนวทาง ต่างๆ เขียนลงบน Post-it อีกสีที่แตกต่างจากสีของความท้าทาย แล้วก็แปะลงไปตรงความท้าทายแต่ละอัน
  • ให้ทีมเลือกมาประมาณหนึ่งถึงสอง แนวคิด หรือแนวทาง ที่ทีมต้องการพัฒนา และปรับปรุงให้ดีขึ้น เพื่อนำไปลงมือทำ

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

จริตที่ 7: แสดงความชื่นชมกันบ่อยๆ

Agile-Behaviours-Show-appreciation

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

จริตที่ 8: เตรียมตนให้พร้อมก่อนเริ่ม Standup Meeting

Agile-Behaviours-Walk-through-your-tasks-B

หลายๆ ที่ที่นำแอจไจล์เข้าไปใช้ หรือแอจไจล์เริ่มเข้าไปคุกคามชีวิตจะมีกระดานเกิดขึ้น บ้างก็เรียกขานว่า Task Board บ้างก็ Kanban Board บ้างก็ Scrum Board (อีอันหลังนี่จะบอกว่า ลด ละ เลิก การเรียกว่า Scrum Board และให้เรียกว่า Sprint Backlog) และก่อนที่จะเริ่มพิธีกรรมที่ทุกๆ คนที่เป็นสมาชิกในทีมพัฒนาและส่งมอบซอฟต์แวร์ต้องไปยืนกันอยู่หน้าบอร์ดนั้น บ้างก็เรียกว่า Daily Scrum (เมื่อคุณใช้ Scrum) บ้างก็เรียกว่า Daily Sync Up/Daily Standup Meeting (เมื่อคุณทำงานเป็น Iteration) ให้สมาชิกแต่ละคนไปดูที่งานของตนเองก็ถูกเขียนลงบน Post-it ว่ารายละเอียดครบถ้วนไหม มีอะไรต้องตัดส่วนที่เกิน และเติมส่วนที่ขาด เพื่อเตรียมความพร้อมก่อนที่จะเริ่มพิธีกรรม เพื่อไม่ให้เกิดอาการ “Post-it กูอยู่ไหน” (พร้อมทำท่าแบบ จา พนม)

จริตที่ 9: ร่วมด้วยช่วยกัน

Agile-Behaviours-Help-me-to-help-you

งานล้นมืออยู่จ้า!!! เราถูกสอนให้สนใจและมีสมาธิกับงานที่มีลำดับความสำคัญสูงสุด ณ เวลานั้นๆ ดังนั้นก็ต้องเรียนรู้ที่จะพูดว่า “ไม่” เมื่อเราเองก็มีสิ่งที่จะต้องทำอยู่เต็มเวลาที่จัดสรรไว้แล้วในแต่ละวัน ซึ่งหลายต่อหลายครั้งที่เราอาจจะต้องไปช่วยเพื่อนร่วมทีมคนอื่นๆ เมื่อเขาเจอปัญหาและเราช่วยได้ แต่ก็จะเจอว่างานที่มีในมือก็เต็มๆ อยู่แล้ว วึ่งเราแก้ไขได้ง่ายๆ ด้วย เราสามารถร่วมด้วยช่วยกันได้อย่างไรบ้าง เพื่อให้เราทั้งสองสามารถจบงานของกันและกันลงได้ทั้งคู่ แล้วก็ค่อยๆ คิดกันดู

จริตที่ 10: ปรับปรุงและพัฒนากระบวนการทำงานด้วยการทดลองเล็กๆ เสมอ

Agile-Behaviours-I-have-an-idea

ถ้าจะต้องปรับปรุงและพัฒนากระบวนการทำงานให้ดีขึ้นเรื่อยๆ แนะนำให้ใช้แนวทางของ การทดลองเล็กๆ (Small Experiment)มากกว่า เปลี่ยนวิธีการใหญ่ๆ ทีเดียว (Change) โดยเราสามารถจะชวนตัวแทนของทีมมาร่วมทำการทดลองเล็กๆ โดยมีพิธีกรรมของการทดลองดังนี้

  • เริ่มต้นด้วยคำถามว่า “ทำไมเราต้องปรับปรุง “
  • เราคาดหวังผลที่จะเกิดจากการทดลองนี้อย่างไร
  • เราจะเริ่มต้น และสิ้นสุดการทดลองนี้เมื่อไร

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

จริตที่ 11: ถามคำถามนี้ “เราสามารถลงมือทำอะไรได้เลยทันที ที่จะช่วยให้เราจะทำงานได้ดีขึ้น” บ่อยๆ

Agile-Behaviours-Now-A

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

สรุป

ตอนผมอ่านบทความ 12 seemingly normal things Agile people do ครั้งแรก ผมต้องกลับไปเลื่อนขึ้นไปบนสุด แล้วก็ค่อยๆ นับทีละหัวข้อ แล้วได้คำตอบออกมาคือเลข 11 อ้าวแล้วทำไมคนเขียนถึงจั่วหัวว่า 12 หล่ะครับ!!!

ในใจแอบคิดว่าน่าจะมีนัยยะ อะไรบางอย่างซ่อนอยู่แน่ๆ

จนกระทั่งมีคนเข้าไปถามใน Comment ของบทความนี้

Screen Shot 2559-04-09 at 10.58.51 PM

ส่วนตัวของผมเองนั้นผมนิยมการพูดคุย ไม่ว่าจะแบบใดๆ ที่มากกว่าคุยกับตัวเอง (บ้า) จะใช้การวาดภาพ เสมอไม่ว่าจะบนไวท์บอร์ด กระดาษ Flip Chart หรือกระดาษ ด้วยปากกาสีเดียว หรือหลากสี (ถ้ามี) เพื่อให้ทุกๆ คนเห็นภาพตรงกัน ไม่มโนไปไหนต่อไหน ไม่ตีความ ไม่คิดเองเออเอง

อีกเรื่องคือการกำหนดกรอบเวลา (Timeboxed) เสมอ เมื่อจะลงมือทำอะไร และการลงมือทำ หมายความว่า เราต้องลงแรง และเวลา ผมโดนสอนมาว่าให้ Work Smart Not Work Hard และมาเจอกับ minimize output to MAXIMIZE OUTCOME เข้าไปอีก เลยนิยมที่จะใช้การทดลองเล็กๆ พร้อมกับเก็บผลลัพธ์ที่เกิดขึ้นดูสิว่ามันช่วยแก้ไขปัญหา หรือปรับปรุงให้ดีขึ้นมากน้อยเพียงใด ตามที่เราคาดการณ์ไว้ในลักษณะของ ตัวชี้วัด

อีกเรื่องที่อยากจะฝากไว้คือ อย่ากลัวที่จะเกิดความผิดพลาดขึ้น และเรียนรู้จากความผิดพลาดนั้นเสมอ เพื่อเราจะพลาดน้อยลง และสัมฤทธิ์ผลมากขึ้นเรื่อยๆ นะจ๊ะ

ก็หวังว่าบทความนี้ที่เกิดจากต้นฉบับของ Mattias Skarin รวมกับประสบการณ์ส่วนตัวของผมจะมีประโยชน์กับเพื่อนพ้องน้องพี่ที่หลงเข้ามาเสพนะครับ

ย้ำ อีกครั้ง ไม่ต้องเฉพาะทีมพัฒนาซอฟต์แวร์ด้วยแอจไจล์เท่านั้นที่จะต้องทำ เราๆ ทุกๆ คนสามารถนำจริตเหล่านี้ไปปรับใช้ได้ ไม่ว่าทำงานอะไรจ้า

วันเสาร์ที่ 9 เมษายน พ.ศ. 2559 เวลา 23:06 น.
อำเภอบางมูลนาก จังหวัดพิจิตร