3 สิ่งที่อยากย้ำ เมื่อทำ Agile
เมื่อวาน Lean In ได้มีโอกาสคุยกับทีมทำ Product ทีมหนึ่งในช่วง Coaching Session เลยอยากจะบันทึกเอาไว้สักหน่อย เผื่อจะเป็นประโยชน์กับคนที่ทำ Agile กันอยู่นะครับ
บริษัทใหญ่ๆโดยทั่วไปมักจะเคยชินกับการวางแผนประจำปี แผนนี้อาจจะเริ่มจากฝั่ง Business มีไอเดียอะไรบางอย่างแล้วก็โยนมาให้ฝั่ง Tech ทำ และส่วนใหญ่จะมีธงปักมาให้เรียบร้อยว่า “ต้องได้” เมื่อไหร่ ฝั่ง Tech เห็นแล้วร้องโอ้โฮ ดูก็รู้ว่าทำไม่ทัน ไหนจะมี Technical Dept ที่สะสมไว้ ไหนจะมีจะมีงานซ่อมงานแทรกที่ไม่รู้จะมาเมื่อไหร่แต่มาแน่ๆ เขาให้ทำแผนก็ฝืนทำไป ทั้งทีรู้ว่าทำไม่ได้หรอก แต่มันก็วนซ้ำอย่างนี้มาทุกปี ถึงแม้จะเปลี่ยนมาทำ Agile แล้ว แต่ก็ยังมี Roadmap มากำกับเหมือนเดิม ที่เพิ่มเติมคือแรงกดดัน แต่ก่อนนานๆมาที ตอนนี้มาทุกสองสัปดาห์ ทีมก็เหมือนจะทำทุกอย่างตามตำราแล้ว แต่คนก็ยังทยอยออกเรื่อยๆ รุ่นแล้วรุ่นเล่า
สิ่งที่จะช่วยให้เราออกจากวังวนนี้ได้ คือการเริ่มต้นปรับมุมมอง 3 เรื่อง:
(1) Common Goals - ทั้ง Business และ Dev ทำงานร่วมกันเป็นทีมเดียวกัน มีจุดหมายร่วมกัน
(2) Outcome Over Output - ให้ความสำคัญกับการทำให้เกิดผลสำเร็จตามเป้าหมายนั้น มากกว่าแค่ทำให้เสร็จตามแผน
(3) Embrace Change - ยอมรับความจริงที่ว่า แผนที่วางไว้จะไม่เคยเป็นจริงตามแผน และมันเป็นเรื่องปกติ
รอยร้าวที่เคยมีระหว่างฝั่ง Business และ Tech อาจจะฝังรากลึก ความไว้เนื้อเชื่อใจกันอาจจะมีน้อย สิ่งที่จะช่วยประสานรอยร้าวตรงนี้ได้เริ่มต้นจากการสร้าง Common Goals โดยอาจจะเริ่มจากการจัดให้ทั้ง Business และ Tech มาคุยกันว่า ภาพความสำเร็จของเราคืออะไร เรามักจะเรียกเป้าหมายร่วมกันนี้ว่า Product Goals
แน่นอนว่า Product Goals เรามักจะยิ่งใหญ่อลังการ และไม่สามารถทำให้บรรลุได้ในเร็ววัน แต่เราเริ่มโฟกัสกับปัจจุบันได้ โดยการตั้งคำถามว่าแล้ว Release แรกที่เราจะปล่อยออกไปให้ใช้ได้จริงๆนั้นภาพความสำเร็จนั้นจะเป็นอย่างไร ซึ่ง Release นี้ควรใช้เวลาสั้นๆระดับเช่นสองสามเดือน หรือบางทีเราก็อาจจะวางว่าเราจะมี Release ทุกไตรมาส เราเรียกนิยามความสำเร็จนี้ว่า Release Goals
จากนั้นเราก็เริ่มทำ Sprint แรกกันได้เลย ไม่ต้องรอ Sprint 0 ไม่ต้องตั้งท่านาน ไม่ต้องรอให้มี Scrum Master ไม่ต้องรอให้มี Product Owner สิ่งที่สำคัญที่สุดที่ต้องมีคือการสร้างให้เกิด Feedback Loop ของการเรียนรู้ ซึ่ง Sprint นับเป็นเครื่องมือที่ทรงพลังที่สุดในปัจจุบันที่จะทำให้เกิดวงจรของการเรียนรู้นี้
ก่อนจะเริ่ม Sprint เราก็มานิยามร่วมกันว่า Sprint Goals ของ Sprint นี้คืออะไร แล้วสอบทวนไปว่ามันยังล้อกับ Release Goals อยู่ไหม จะได้ไม่หลุดโฟกัส อะไรที่ไม่อยู่ใน Release Goals ปัจจุบัน ก็ไม่ควรจะอยู่ใน Sprint Goals ปัจจุบัน
เราวางแผน Sprint โดยการตกลงกันว่าจะมีงานอะไรบ้างที่เราจะทำ ตำรา Scrum เรียกงานนี้ว่า Product Backlog Item และเรามักจะถูกสอนให้ใช้ User Story กันโดยเฉพาะในงานทำ Software ซึ่งหลายๆครั้งเรามัวแต่ไปหมกมุ่นกับการเขียน Story ให้ถูก จนอาจทำให้เราหลงประเด็นว่า จริงๆแล้วเราทำงานแบบ Sprint ไปทำไม
ที่เราทำงานเป็น Sprint เพราะเราต้องการที่จะทำให้เกิดการเรียนรู้ให้มากที่สุดจากวงจรของการเรียนรู้ เพราะตระหนักรู้ว่าเรากำลังต่อสู้กับความไม่รู้ อยากจะชวนว่าแทนที่จะไปให้ความสำคัญกับรูปแบบของ Story ให้เราลองเปลี่ยนมามองว่า Item แต่ละอันนั้นคือ Showcase Item ที่จะเอาให้ลูกค้ามาลองเล่นตอนจบ Sprint เราอาจจะตั้งชื่อ Item ให้เป็นรายการของที่จะไป Showcase ตอนจบ Sprint ที่ใครเห็นก็เข้าใจและแปะ List นี้ไปใน Agenda ตอนเชิญมา Showcase ได้เลย เราอาจจะตั้งชื่อให้มันง่ายขนาดว่า Business มาดู Sprint Backlog แล้วพอเข้าใจว่า Tech ทำอะไรอยู่ มีรายการเดียวไม่ต้องมีใครคอยแปลภาษา เพื่อให้ Business กับ Tech เข้าใจกันมากขึ้น เข้าใกล้กันมากขึ้น
เราจะไม่ได้วางแผนให้มี Release 1 แล้วต่อด้วย Release 2 แล้วต่อด้วย Release 3 เราจะมีแค่ Release นี้กับสิ่งที่ยังไม่อยู่ใน Release นี้ (เอาไปเก็บไว้ใน Product Backlog ก่อน) เราไม่ได้วางแผน Sprint ล่วงหน้าหลายๆ Sprint เพราะเราจะโฟกัสกับสิ่งที่อยู่ใน Sprint นี้ ในทางปฏิบัติแล้วแน่นอนว่าเราอาจจะเหลือบไปดู Sprint ล่วงหน้าได้บ้าง วางแผนของ Release หน้าได้บ้าง ให้พอจะนัดส่งต่องานกับคนอื่นได้ ให้พอเห็นภาพ โดยการ "ตำข้าวสารกรอกหม้อ" สะสมงานไว้ในช่วง Grooming แต่มันจะไม่น้อยไปและไม่มากไป ทั้งนี้ทั้งนั้นเราจะไม่ได้ไปลงรายละเอียดกับมันมากนัก เพราะยังไงมันก็จะเปลี่ยนอยู่ดี
สิ่งสำคัญไม่ใช่การทำให้เสร็จตามแผนที่วางไว้ตั้งแต่ตอนเรารู้น้อยที่สุด และพยายามปิดกั้นการเปลี่ยนแปลง แต่เป็นการสร้าง Feedback Loop ให้เอาสิ่งที่เราเรียนรู้มาปรับแผน และสื่อสารกับทั้งคนที่เราทำงานอยู่รวมไปถึงผู้บริหาร ให้ทำงานไปด้วยกัน เพื่อให้มั่นใจว่าเรายังโฟกัสกับภาพความสำเร็จของ Release ซึ่งเป็นส่วนหนึ่งของ Product Goals มากกว่าทำให้เสร็จตามแผน
ในช่วงเริ่มต้นหลายๆคนจะมีความกังวลกับธงที่ผู้ใหญ่ปักมา แต่จากประสบการณ์หลายสิบปีที่ผ่านมา ผมยังไม่เคยเจอว่ามีใครโดนไล่ออกเพราะทำงานไม่ทัน และยิ่งยุคนี้สมัยนี้โปรแกรมเมอร์เก่งๆนั้นมีค่ายิ่งกว่าทองคำ จริงๆแล้วผู้บริหารนั้น กว่าที่เขาจะก้าวชึ้นไปถึงจุดนั้นได้ เขาผ่านร้อนผ่านหนาวมากมากพอที่จะรู้ว่า แผนมันจะไม่เป็นไปตามแผน เพียงแต่เขาอาจจะยังไม่รู้จักวิธีอื่นนอกจากการปักธงและกดดัน ซึ่งก็เป็นหน้าที่ของเราที่จะเปิดโอกาสทางการศึกษาให้กับผู้บริหาร โดยเฉพาะถ้าเรามีโอกาสทองที่เรียกว่าการทำ Pilot เราก็บอกไปเลยว่า Agile นั้นทำงานแบบนี้ หรือถ้ามีโค้ชอยู่ด้วยก็อ้างไปเลยว่าโค้ชบอกมา ถ้าสงสัยให้ไปถามโค้ชดู
เราอาจชวนผู้บริหารให้คิดว่าถ้าทำแบบเดิม ก็ได้ผลเหมือนเดิม เร่งเอาของพังๆออกไปก็ต้องมาใช้กรรมที่หลังอยู่ดี จะให้เข้าทีเอาความจริงมาคุยกันตั้งแต่ตอนนี้ดีกว่า และการรวบรวมความกล้าที่จะพูดความจริงนี้คือจุดสำคัญที่จะลดรอยร้าวระหว่าง Business และ Tech เพราะความหอมหวานที่เกิดขึ้นจากการส่งงานทันตามกำหนดนั้นเป็นเพียงเรื่องชั่วครั้งชั่วคราว แต่ความขมชื่นที่เกิดจากของไปพังคามือลูกค้นนั้นจะอยู่กับเราไปอีกนานเท่านาน ถ้าเราไม่อยากทยอยเขียนใบลาออกให้ตัวเอง ก็ควรจะเริ่มรวบรวมความกล้าที่จะเอาความจริงมาคุยกันเสียตั้งแต่วันนี้
Agile นั้นเป็นการอยู่กับปัจจุบัน โดยไม่ห่วงอนาคตที่ยังมาไม่ถึง และไม่พะวงอดีตที่อยู่ข้างหลัง
ขอให้มีความสุขในการกินข้าวที่ละคำ ทำทีละ Sprint นะครับ
1ถูกใจ
3แชร์
7Kรับชม
แสดงความคิดเห็นของคุณ...
