Anti-pattern ที่นิยมใน SCRUM: กฎเหล็กที่ใช้เป็นแรงผลักดันทีม

- Christopher Alexander, A Pattern Language

อะไรคือ anti-pattern?

Anti-pattern นั้นเกิดขึ้นเมื่อเราเชื่อว่าโซลูชั่นที่เรากำลังนำเสนอเพื่อแก้ไขปัญหานั้นดูเหมือนว่าจะเป็นโลูชั่นที่ใช่และง่ายที่สุดแล้วในการติดตั้งใช้งาน แต่ทว่าสุดท้ายก็จบลงด้วยการพบปัญหาหรือก่อเกิดปัญหาอื่นๆ ตามมามากมาย มากกว่าที่ปัญหานั้นจะได้รับการแก้ไขเสียอีก anti-pattern นั้นมักซ่อนเร้นแอบแฝงอยู่ใน best practice และเหมือนว่าจะเป็นส่วนหนึ่งของระบบเสียด้วย

Anti-pattern ใน SCRUM

จากประสบการณ์ของผม anti-pattern บางรูปแบบที่ผมเห็นว่าเกิดขึ้นสม่ำเสมอในทีมและองค์กรนั้นได้แก่:

การเชื่อว่าเมื่อเราใช้กระบวนการ SCRUM แล้ว เราจะมีความเป็น Agile เกิดขึ้น

ผมมักจะพบเสมอว่าองค์กรที่ใช้กระบวนการ SCRUM มานานหลายปีนั้นก็เชื่ออยู่ในตัวเองว่ามีความเป็น AGILE อยู่ในตัว (เรียนรู้เพิ่มเติมเกี่ยวกับการบริหาร Agile Project Management ของผมเองและ  Agile Coaching approach ได้ที่นี่) อย่างไรก็ตาม เมื่อมองให้ลึกซึ้งถึงทีมต่างๆ จะเผยให้เห็นว่าพวกเขานั้นติดอยู่กับแนวทางการทำงานแบบดั้งเดิมตามที่เคยทำมา

เพื่อให้เกิดการเปลี่ยนผ่านได้จริง จำเป็นที่จะต้องเสริมแรงให้แก่ Agile Mindset เราควรย้อนกลับไปที่ต้นตอของเรื่องซึ่งก็คือ Agile manifesto ที่ซึ่งประกอบด้วยคุณค่า 4 ประการและหลักการทั้ง 12 ข้อ

สิ่งนี้จะช่วยให้เห็นภาพที่ชัดเจนของ Agility ในฐานะเป็นภาพรวมใหญ่สุดของ practice และ framework ต่างๆ ที่อยู่ใต้นั้น หากเราปฏิบัติเพียงแค่ตาม practice ที่มี (ซึ่งมันก็มีอยู่มากมาย) แต่เราไม่ได้ปฏิบัติตามทั้งหมดให้สอดคล้องกันกับคุณค่าและหลักการที่เกี่ยวข้อง เราจะกลับพบว่า เรากำลังอยู่ในขอบการทำงานแบบ fake Agile ที่ไม่ตรงกับสิ่งที่ต้องการให้เกิดขึ้นจริงเลย

สำหรับการวางแผนแล้ว Product Owner ควรจะมอบหมายงานให้แก่ Developers

เป็นเรื่องสากลที่ว่าการวางแผนนั้น ผู้ที่มีบทบาทเป็น Product Owner จะต้องกำกับดูแลการทำงานของนักพัฒนาว่าจะต้องปฏิบัติงานอย่างไร แต่ในขณะเดียวกันก็ไม่ได้พยายามที่จะนำเสนอความเป็นองค์กรในตนเองและการสร้าง commitment ในการทำงานของตนเอง ผมแนะนำว่า Scrum Master ที่มีประสบการณ์ควรจะทำงานร่วมกับ Product Owner เพื่อปรับปรุงเรื่องของความเข้าใจในบทบาทนี้ ข้อนี้จะช่วยให้นักพัฒนามีอำนาจในการตัดสินใจในการทำงานมากขึ้นอย่างเต็มที่

การตรวจงานกลายเป็นเหตุการณ์ที่ Product Owner จะมีโอกาสได้เช็คความถูกต้องของงานในทีมนักพัฒนาได้

ใน SCRUM นั้นประกอบด้วยบทบาท 3 บาทบาทได้แก่ Scrum Master, Product Owner และ Developers บทบาทเหล่านี้คือองค์ประกอบสำคัญของการทำงานเป็นทีม และจะไม่มีการแยกทีมย่อยหรือ sub-team ใดๆ อย่างไรก็ตาม ผมได้มีโอกาสได้ประสบกับเหตุการณ์ที่ทีมขาด Product Owners ในทีมงานของ SCRUM team และ Product Owners บางคนทำหน้าที่เพียงแค่การวางแผนและการตรวจงาน แต่ไม่นำเสนออะไรในช่วงของการทำ sprint และบ่อยครั้งก็เข้าไปประชุมร่วมใน daily event เพียงเพื่อแค่ติดตามงานเท่านั้นเอง

ข้อเสนอของผมในกรณีนี้คือ ต้องทำให้มั่นใจว่า Product Owners ได้รับการอบรมอย่างเหมาะสมในหน้าที่ และบุคคลที่มีต้องมีทรัพยากรเวลามากพอที่จะมารับบทบาทต่างๆ ให้เติมเต็มด้วย

การทำ retrospective การประชุมแบบครึ่งชั่วโมงที่ซึ่งไม่มีใครต้องการที่จะเข้าร่วมประชุมด้วย

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

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

Product Owners รับบทบาทในฐานะเป็น หัวหน้าของทีม

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

เพื่อป้องกันมิให้สถานการณ์เลวร้ายไปมากกว่านี้ จึงจำเป็นที่จะต้องเสริมแรงให้แก่ Agile mindset ในทีมการทำงาน และเริ่มปรับปรุงความเข้าใจของ Product Owners เรื่องของบทบาทของตนเองผ่านทางการอบรมและการสอนงานแบบ mentoring

ความเข้าใจผิดเกี่ยวกับ Sprints

เมื่อองค์กรต่างๆ กำลังเปลี่ยนแปลงไปสู่การทำงานแบบ Agile พวกเขามักจะตีความเอาง่ายๆ ว่ามันคือการออกแบบผลิตภัณฑ์ในรุปแบบของการทำ sprints ที่ประกอบด้วยการสร้าง Gantt chart แบบใหม่ๆ กับการสร้างสภาพแวดล้อมการทำงานที่มีการแข่งขันสูง มีความกดดัน และความเสียหายจากการส่งเลย deadline จริงๆ แล้ว SCRUM ไม่ใช่แค่การบริหารจัดการโครงการ แต่นั่นเป็นการสร้างผลิตภัณฑ์ในสภาพแวดล้อมที่ไม่มั่นคง ที่ซึ่งเป็นจุดที่ทำให้คุณค่าของการทำงานลดลง

เช่นเดียวกัน ผมแนะนำให้เสริมแรงแก่ Agile mindset ท่ามกลางทีมของคุณ คุณอาจจะต้องสร้าง product pilot ก่อน และเรียนรู้จาก pilot นี้เพื่อปรับปรุงวัฒนธรรมใหม่

การคิดแบบ SCRUM ช่วยให้เราผลักดันให้ผลิตภัณฑ์ออกสู่ตลาดได้เร็วกว่าเดิม

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

SCRUM Master กลายเป็น Project Manager ใหม่ไปแล้ว

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

ในความเป็นจริง วัตถุประสงค์ของบทบาทนี้จะช่วยให้ทีมสร้างคุณค่าได้ พวกเขาต้องพัฒนาทักษะ ความสามารถ และความรู้ ให้เกิดขึ้นอย่างต่อเนื่องไปจนถึงการออกจากโครงการ SCRUM Master ต้องช่วยเหลือ Product Owner ค้นหาทางที่ดีที่สุดในการบริหารจัดการรายการของความสำคัญจำเป็น สอนทีมงานให้ขจัดอุปสรรค และยกเลิกกิจกรรมที่ไม่ตอบโจทย์วัตถุประสงค์ของโครงการ พวกเขาต้องอำนวยความสะดวกให้แก่กิจกรรมที่เกี่ยวกับ Agile และช่วยเหลือองค์กรให้เปลี่ยน mindset จากรากฐานเลย และที่สำคัญ SCRUM Master นั้นไม่ใช่คนที่ต้องทำการตัดสินใจเกี่ยวกับเรื่องทรัพยากรบุคคล ผลิตภัณฑ์ ตารางงาน หรือการมอบหมายงานที่กำลังค้างคาอยู่

"เรากำลังทำงานเกือบจะตรงเวลา แต่ขอขยาย sprint ไปอีก 2 วันนะ"

เมื่อเราอยู่ในสถานะที่ควบคุมทุกอย่างได้แล้ว SCRUM team ก็จะสามารถถูกกำกับดูแลเพื่อให้ขยายเวลาของการทำ sprint ได้ นั่นหมายความว่าจะไม่มีกำหนดระยะที่คงที่เป็นจังหวะคงที่ในการนำส่งมูลค่า หรือในการตรวจสอบคุณค่าที่สร้างขึ้นมาในแต่ละรุ่นของผลิตภัณฑ์

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

"ในการทำ sprint นั้น เราทำที่ frontend และจากนั้นก็ทำที่ backend และจากนั้นก็จะเข้าสู่กระบวนการ test"

เมื่อเราไม่แบ่งเรื่องต่างๆ ออกเป็นระยะที่เหมาะสม เราจะพบว่าเรากำลังเจอ Agile waterfall products อยู่ โดยหนึ่งในวัตถุประสงค์ของการแยก user story ออกเป็นระยะๆ ให้เหมาะสมนั้นคือการสามารถที่จะสร้าง product ขนาดเล็กเพิ่มขึ้นมา นับว่าเป็นเรื่องไร้ประโยชน์ที่จะต้องสร้าง screen ที่ไม่มีฟังก์ชั่นการใช้งานใดๆ เลย นั่นไม่มีประโยชน์ต่อ user ที่จะต้องมาตรวจขั้นตอนการทำงานใดๆ สิ่งนี้ยังไปก่อให้เกิด block ที่เกิดจากวิสัยทัศน์ทางเทคนิคที่ user ไม่สามารถจะปฏิสัมพันธ์กันได้ ถ้าเล่าให้ง่าย หาก user ไม่สามารถให้ feedback ได้ คุณจะไม่สามารถคาดหวังการปรับปรุงที่สมเหตุสมผลได้เลย

ทางที่ดีที่สุดต่อการปรับปรุง ก็คือการสร้างฟังก์ชั่นเล็กๆ มีคุณภาพที่สูงขึ้นมาได้ จนเกิดวิวัฒนาการต่อเนื่องไปเป็นฟังก์ชั่นที่มีความสามารถสูงขึ้นได้เรื่อยๆ นั้น ประสบการณ์ของการพัฒนาซอฟต์แวร์ของเราและการออกแบบ UX/UI ของเรานั้นจะไม่สามารถสร้างประโยชน์จากทรัพยากรบุคคลที่มีอยู่ได้เลยหากไม่มี feedback จาก user ที่หนักแน่นพอ

บทสรุป

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

หากต้องการติดต่อทีมงานของเราเกี่ยวกับการแบ่งปันประสบการณ์ของคุณ ทีมและผมเองยินดีเป็นอย่างยิ่งที่จะสนทนากับคุณเกี่ยวกับเรื่องราวดีๆ เหล่านี้ที่ห้อมล้อมด้วยเทคโนโลยี นวัตกรรม และ Agility