Agile Hypersprint … Why What How ???

ฮ่าๆ เปิดหัวเรื่องปุ๊บ ก็งงในงงกันเลยสินะครับ … โอเคครับ วันเสาร์ที่ผ่านมา (3 Aug 2019) ผมได้มีโอกาสเข้าร่วมกับงาน Agile Thailand 2019 #ath2019 ซึ่งการเข้าร่วมงานครั้งนี้ นับเป็นครั้งที่…1 ครับ ฮ่าๆ โดยงานนี้เขาจัดมาหลายปีแล้วนะครับ ถ้าจำไม่ผิด นี่น่าจะเป็นครั้งที่ 8 แล้ว *0* เอาล่ะ ไหนๆก็ไปมาแล้ว จะไปโดยไม่ได้อะไร มันเป็นไปไม่ได้สำหรับโผมม วันนี้ผมก็เลยจะมาแชร์ความรู้ต่อเรื่อง Agile Hypersprint ที่ได้จากการเก็บเกี่ยวมานะครับ โดย Hypersprint มันมีกิมมิค (gimmick) เล็กๆน้อย ต่างจาก Agile ธรรมดาๆ อยู่นิดหน่อย เดี๋ยวค่อยๆอ่านไปนะครับ

อันดับแรก การที่เราจะเข้าใจอะไรง่ายๆ ผมพบว่า มันน่าจะดีกว่าไหม ถ้าเจอกับคำถามง่ายๆ ก่อนว่า

• Why? (ทำไม…ต้องทำ)
• What? (อะไร…ที่จะช่วยได้)
• How? ((ทำ)อย่างไร…ถึงจะบรรลุเป้าหมาย)
• Conclusion (ใช้แล้วจะดี หรือ ไม่ใช้ก็ดี)

หัวข้อวันนี้เลยจะแบ่งหัวข้อตามนี้เลยละกันนะครับ

Photo by Ken Treloar on Unsplash

Why ?

ก่อนที่เราจะรู้ว่า Hypersprint มันคืออะไร ผมอยากให้ทุกท่านลอง Step Back มาก่อนว่า วิถี Agile เดิมๆ เราพบปัญหาอะไรบ้างไหม หรือเราต้องการจะพัฒนาอะไรให้มากขึ้นบ้างไหม … เราพบว่า Default หลายๆคน ก็นิยามไว้ว่า Sprint หนึ่งๆ จะใช้เวลาประมาณ 1–2 weeks ดังนั้นสโคปงานสำหรับ 1 Sprint ก็เลยค่อนข้างใหญ่อยู่พอตัว อีกอย่างปัญหาที่พบกันก็คือ Fail Sprint Commitment (หรืออาจจะพบได้ในคำว่า Sprint Forecast) เพราะว่า ไม่ว่ายังไง เราก็ไม่รู้อนาคตอยู่ดี ว่างานที่เราทำมันจะเสร็จ เราทำได้แค่ “คาดเดา” ว่าจะเสร็จทันเวลา ถ้าคนชำนาญมากๆ ก็แค่คาดเดาได้ใกล้เคียงมากที่สุดเท่านั้นเอง จึงเป็นสาเหตุที่ว่าการทำ Sprint แรกๆ แทบจะการันตีไว้ได้เลยว่ามีโอกาสพลาดสูงมากแน่นอน และอีกอย่างคือ Fail Sprint บ่อยๆ ไม่ดีแน่ๆ เหมือนอารมณ์เราทำงานที่มีระยะเวลาแน่นอน แล้วก็ทำไม่เสร็จ พอไม่เสร็จก็ลุกลามไป process ต่อไป เป็นอย่างนี้ไปเรื่อยๆ จนเรามี Mindset ว่า ไม่เสร็จแล้วไง ใครแคร์~~ … That sounds bad :(

แล้วถ้าเราอยากลอง Accelerate มันล่ะ ให้ไวขึ้น ส่งมอบได้บ่อย เห็นผลไว อย่างน้อยๆก็ Avoid ปัญหา Fail Sprint ได้บ้าง จะทำยังไง มีวิธีไหม

ทีนี้ก็ผุดแนวความคิดที่ว่า หากเราลองปรับเปลี่ยน mindset ไปว่า ถ้าลอง Break Down งานให้เล็กๆ แล้ว Sprint ละ 1–2 วันล่ะ จะได้มี Sprint Commitment ที่ดีขึ้น โอเคไหม … ละนี่ก็คือ ส่วนแรกของ Hypersprint

Photo by SpaceX on Unsplash

What ?

พอเรารู้แล้วว่า pain point เล็กๆที่ก่อให้เกิดปัญหาที่ยิ่งใหญ่ มันคืออะไร เราจะมาทำลาย Old Habit เก่าๆ Mindset เก่าๆ ไปสู่ Hypersprint กัน ​… จากหัวข้อที่แล้วที่บอกว่าทำ Sprint ให้เหลือ 1–2 วัน แล้วมันมีอะไรอีกบ้างไหม ผมขอลิสต์องค์ประกอบคร่าวๆ ไว้เป็น bullet เลยละกันครับ

• Sprint for a day or two! 🚀
• Work Break Down to the smallest one! ⬛️ → ▪▪▪▪️
• Pair (programming, design, etc.) Only! 👭
• Make Tasks Transparency! ❌ ⭕️
• Break the old environment! 🆕
• Have a Coach for the first start! 🏅 (MUST REQUIRED)

ครับ ไม่เยอะไปใช่ไหม ลดระยะเวลา Sprint,​ ย่อยงานให้เล็กที่สุดสำหรับ 1–2 วัน, จับคู่ทำงานเสมอ ! ย้ำว่า เสมอ ! (ไม่จำเป็นว่าต้องเป็น Dev เป็น Programmer งานอื่นๆ อาทิเช่น Design ก็ได้ครับ) ช่วงแรกๆ อาจจะช้า เนื่องจากการปรับตัว, เขียนงานเป็น Task ให้ชัดเจนไม่พอ ต้องให้ทุกคนรู้ด้วยว่า ใครทำอะไรอยู่ ใครพอกหางหมูไว้ ใครว่างเกินไปแล้ว (หลายๆ คนอาจจะใช้ Tools อาทิเช่น Trello หรือแม้กระทั่ง Physical เช่นการแปะ Post-it ก็ได้ครับ), ทำลาย Partition โต๊ะทำงาน ให้มานั่งด้วยกัน โต๊ะเดียวกัน ใกล้ชิดให้มากๆ เพื่อที่จะให้พวกเขาเหล่านั้น ได้พูดคุย ได้ถกเถียงปัญหาได้ทันที, และสุดท้ายต้องมีโค้ชที่ชำนาญคอยแนะนำ อันนี้สำคัญมากนะครับ เพราะไม่ใช่ใครก็ได้ ที่จะมาสอนแนวทางให้ทำงานต่างๆ ได้ภายใน 1 วัน ค่อนข้างหายากเลยทีเดียว

Photo by Marvin Meyer on Unsplash

How ?

พออ่านไปได้สักระยะ หลายท่านก็คงตั้งคำถามในใจ อ่าว… 1–2 วัน จะแบ่งเวลาทำงานอะไรได้ยังไง ​… อย่างที่บอกครับว่า ต้องย่อยงานให้เล็กที่สุด เพื่อให้งานนั้นสามารถทำเสร็จได้ใน 1 วัน (ไม่ใช่รุมกันทำงานใหญ่ๆให้เสร็จ 1 วันนะครับ ต้องย่อยงานต่างหาก อย่าเพิ่งเข้าใจผิดกันเด้อ) เพราะฉะนั้นการแบ่งเวลาจะเป็นประมาณนี้ครับ

case "1 day" {
   "planning"                    : "less than 60 minutes",
   "standup_meeting"             : "less than 15 minutes",
   "refine_review_retrospective" : "less than 90 minutes"
}
case "2 days" {
   "first_day_planning"                   : "less than 60 minutes",
   "first_day_standup_meeting"            : "less than 15 minutes",
   "first_day_refine"                     : "less than 60 minutes",
   "second_day_standup_meeting_morning"   : "less than 15 minutes",
   "second_day_standup_meeting_afternoon" : "less than 15 minutes",
   "second_day_review_retrospective"      : "less than 60 minutes"
}

พอจะเห็นเวลาที่เหลือไหมครับ ว่าเหลือเวลาทำงานจริงๆ เท่าไหร่ … ฮ่าๆๆ ถ้าเคส 1 วันก็จะเหลือประมาณ 3 ชั่วโมง 15 นาที เท่านั้น (เทียบการทำงาน 6 ชั่วโมงต่อวัน + breaks ~2 ชั่วโมง รวม 8 ชั่วโมง) และจะบอกว่า รวมเทสด้วย! ฮ่าๆ อึ้งกิมกี่เลยทีเดียว อย่างไรก็ตาม คนเราต้องพัฒนาตัวเองอยู่เสมอ ต้องผลักดันตัวเองไปข้างหน้าอยู่ตลอดเวลา พยายามออกจาก Comford Zone บ้าง ดังนั้นก็ค่อยๆ ปรับตัวกันไปครับ

Get Comfortable With Being Uncomfortable — Click for More Read

Conclusion (ใช้แล้วจะดี หรือ ไม่ใช้ก็ดี)

สรุปท้ายเรื่องนะครับ Hypersprint จะเป็นเพียงแนวคิด วิถีการทำงาน ที่ช่วย Accelerate งานให้ไวขึ้น ผ่านกระบวนการการย่อยงานให้เล็กที่สุด, Pair การทำงานเสมอ และทำ Sprint ละ 1–2 วัน ทลายแนวคิดเดิมๆ ที่มีมุมมองไม่ค่อยดีกับ fail sprint commitment ปรับเปลี่ยนวิถีการทำงานให้ไวขึ้น ปรับเปลี่ยนสภาพแวดล้อมการทำงานต่างๆ ให้เป็น Teamwork มากขึ้น ทั้งนี้ ผมไม่ได้เป็นคนการันตีว่า องค์กรไหนจะเอาวิธีนี้ไปปรับใช้แล้วจะดีหรือไม่ดี ต้องขึ้นอยู่กับปัจจัยความพร้อมที่ต้องการจะเปลี่ยนของพนักงานฟันเฟืองเล็กๆ ในองค์กรด้วยครับ ว่าพร้อมจะเปลี่ยนกันหรือไม่ หรือวิธีเดิมก็อาจจะดีอยู่แล้ว ก็ไม่ว่ากัน เพียงแต่วันนี้มาแชร์วิธีใหม่ๆ ให้ได้ลองปรับใช้ ลองทำกันดูครับ

หากผิดพลาด ณ​ ประการใดก็ขอประธานอภัยมา ณ​ ที่นี้ด้วยครับ และก็ขอขอบคุณพี่นา Exxonmobil ที่มาแชร์แนวคิด Agile Hypersprint ผ่าน Unconference ในงาน Agile Thailand 2019 และสำคัญไปกว่านั้นขอขอบคุณทีมงานทุกท่าน รวมไปถึงผู้ที่เกี่ยวข้อง และผู้อำนวยความสะดวกเรื่องสถานที่และอาหาร ซึ่งก็คือ ธนาคารกรุงศรีอยุธยา สำนักงานใหญ่ ด้วยครับ ขอบพระคุณอย่างสูงครับ

#AgileThailand2019 #ath2019 | agile๖๖