จริงหรือไม่! Agile Framework แต่ละองค์กรไม่เหมือนกัน o_O!

หลายคนอาจจะมีคำถามว่า เอ๊ะ! ที่อื่นเขาทำ Agile กันแบบไหนนะ? เหมือนที่ TDG ทำกันอยู่หรือป่าวนะ?

ผู้เขียนอยากจะขอแชร์ประสบการณ์บทบาทการเป็น Scrum Master จำเป็น (หน้าที่หลักจริงๆ คือ BA 555+) จากองค์กรเดิมที่เคยทำงาน พอได้มีโอกาสมาร่วมงานกับ TDG เมื่อไม่นานมานี้ก็พบได้ว่า Agile Framework ที่นี่ค่อนข้างต่างกับที่เดิมมากเลยทีเดียวค่ะ

ต้องบอกก่อนเลยว่านี่เป็นการแชร์ประสบการณ์ส่วนตัวของผู้เขียนเท่านั้น ซึ่งเกิดจากการร่วมงานของทีมๆ หนึ่งเท่านั้นนะคะ :)

Factor หลักๆ ที่ผู้เขียนคิดว่ามีผลกับ Agile Framework นั่นก็คือ

“The nature of organization หรือลักษณะขององค์กร” นั่นเอง!!

ผู้เขียนขอเรียกชื่อองค์กรเดิมนามสมมติว่า “องค์กร A” ซึ่งระบบที่ผู้เขียนเคยทำมาก่อนนั้น ต้อง Coordinate กับหลายส่วนงาน Operation, Customer, Payment, Finance, Audit และ IT หากคิดเป็น % ง่ายๆ ของจำนวนพนักงานทั้งหมด จำนวน Users (ที่เป็น Real users) มีประมาณ 90% ส่วนคนทำงาน IT มีเพียงแค่ 10% เท่านั้น

การนำเอา Agile ซึ่งเป็นแนวคิดแบบเชิง IT Software Development มา apply กับพนักงานส่วนใหญ่ซึ่งเป็น Real users นั้น เป็นอะไรที่ “Challenge มาก!” ค่ะ หากยกตัวอย่างให้เห็นภาพง่ายๆ เช่น พูดคำว่า “Waterfall” กับ user แน่นอนว่าต้องเข้าใจว่าเป็น “น้ำตก” แน่นอน ส่วนคำว่า “Agile” น้านนนนน… (คุยกันยาวเลยล่ะค่ะ 555)

Users ก็มักไม่เข้าใจและมีคำถามเสมอว่า Agile คืออะไร? ทำไมต้องทำ? และรู้สึกเสียเวลาแทนที่จะได้ focus ในงาน BAU ที่เป็นงานของตัวเองเท่านั้น และที่นี่ไม่มีตำแหน่ง Scrum Master อย่างชัดเจน เพราะฉะนั้นความลำบากของชาว IT ที่ต้องบุกเบิก Ceremonies ต่างๆ Daily Scrum, Sprint Grooming, Sprint Planning, Sprint Retrospective ก็เกิดขึ้น

องค์กร A จึงมีการลงทุนจ้างบริษัท Agile ชื่อดัง เข้ามาทำ Agile Training ให้พนักงานทั้งองค์กร และบริษัทนั้นก็ได้ design Scrum Team ได้ออกมาในลักษณะนี้

• Users (ใช่ค่ะ! เราให้ Users เป็นส่วนหนึ่งใน Scrum Team ซะเลย 55555) เป็นผู้ให้ requirement และก็จะมีบางครั้ง Developers ก็ได้รับ requirement โดยตรงมาเช่นกันแล้วส่ง requirement ต่อให้ BA
• Developers เป็นผู้ implement/enhance ระบบ ซึ่งมีทั้ง Local IT และ Vendors ต่างชาติ ทำงานร่วมกัน
• BA (ควบ SM) นอกจากจะ analysis requirement แล้ว ก็กลายเป็นรับหน้าที่ create backlog/story ตาม requirement ที่ได้รับมาอีกด้วย
• Business Product Owner จะเป็นผู้บริหารระดับสูงในองค์กร ที่มีอำนาจตัดสินใจว่าจะให้ทีมทำ backlog ไหนเป็น priority ของ Sprint นั้นๆ PO ในที่นี่จึงไม่ได้เป็นคนสร้าง backlog และจะเข้ามา join เฉพาะช่วงทำ Sprint Planning เท่านั้น

เมื่อระยะเวลาผ่านไปด้วยสถานการณ์ต่างๆ ไม่ว่าจะเป็นเรื่องของประชุมที่เยอะทั้งฝั่ง Dev และ Users เพราะระบบและ Business Rule ที่ซับซ้อน ไม่เอื้ออำนวยต่อการทำ Ceremonies ต่างๆ หรือจะเป็น User มีงานทั้ง BAU งาน support Audit และ User ก็ยังมีหน้าที่เป็น QA ของระบบอีกด้วยต้องลงมือ testing เองทุกประการ

Scrum Team จึงเหลือกลายเป็น…

เหลือเพียง 2 Ceremonies เท่านั้น คือ Daily Scrum และ Sprint Planning ซึ่งมีการตกลงกับทีมที่จะรวบ Sprint Grooming เข้ามาใน Sprint Planning อาจจะใช้เวลานานมากหน่อย แต่ทุกคนสามารถคุยร่วมกัน มองเห็น Objective เดียวกันก็ถือว่าเป็นอะไรที่ effective ในการทำงานอยู่ค่ะ

จะเห็นได้ว่าแม้ว่าแต่ละองค์กรจะมีลักษณะ Business, ลักษณะ Product รวมไปถึงบทบาทหน้าที่ของแต่ละคนที่ไม่เหมือนกัน แนวคิด Agile ก็สามารถเอาไปปรับใช้ได้หมดเพียงเน้นการสื่อสารกับทีมให้มากและเป็นการสื่อสารที่มีประสิทธิภาพนั่นเองค่ะ

เมื่อผู้เขียนได้มาเจอการทำงาน Agile Framework ที่ TDG แห่งนี้ก็มีความรู้สึกว่าที่นี่เป็นองค์กร IT ที่ใช้ Agile ครบครันอย่างแท้ทรู ทุกคนเป็นชาว IT ที่เข้าใจหลักการและประโยชน์ของการทำ Agile เต็มเปี่ยมไปด้วยคนรุ่นใหม่ไฟแรงที่พร้อมรับสิ่งใหม่ๆ ตลอดเวลา ได้เห็นงานที่ deliver ออกมาทุกๆ Sprint จากการตั้ง story point ที่ make sense และไม่ overload จนเกินไป ยังมีอะไรอีกมากมายที่ผู้เขียนเองก็ต้องมาศึกษาเพิ่มเติม ณ โรงเรียน TDG แห่งนี้ค่ะ ^^