เลิกดีไหม ทำAgile ย่ำอยู่กับที่(Why Agile is not working?)

https://i0.wp.com/www.wallstreetenglish.in.th/wp-content/uploads/2019/07/shutterstock_639802045-1.jpg

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

คุณทำ Agile เพราะอะไร?

สิ่งเเรกเลยอยากให้ทุกคนลองมองย้อนกลับไปถามตัวเองว่า “เอ๋ เราและทีมทำ Agile เพราะอะไรนะ?” หัวหน้าบอกให้ทำ บริษัทอื่นเค้าทำกันไม่อยากตกขบวน หรือทำเพราะรู้ถึงคุณค่าที่ Agile ต้องการจะมอบให้จึงอยากลองนำมาใช้กับทีม

จากคำถามที่ว่า ทำ “เพราะอะไร?” อาจจะจบว่า ทำ “ทำไม”? และตัวฉันเองได้อะไร?

โดยทั่วไปมนุษย์จะอยากทำอะไรด้วยแรงใจเต็มเปี่ยมก็ต่อเมื่อตระหนักรู้ 2 อย่าง

• เราทำไปเพื่ออะไรใครได้ประโยชน์ และที่สำคัญคือชีวิตเราจะดีขึ้นยังไงจากสิ่งนั้น?
• เราทำ“ทำไม” (Start with why)

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

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

เมื่อทีมเข้าใจความต้องการของตัวเองเเล้ว จิ๊กซออีกชิ้นก็คือ “แล้ว Agile ให้ตอบสนองความต้องการนั้นได้ตรงใจทีมหรือเปล่า” จะตอบคำถามนี้ได้ต้องเริ่มจากการมองโลกผ่านสายตาของ Agile กันก่อน

กำเนิดแนวคิดแบบ Agile

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

“เมื่อความจริงกองอยู่ตรงหน้า คุณจะมีวิธีจัดการกับมันอย่างไร?”

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

1. เป็นไปไม่ได้เลยที่จะรวบรวมข้อมูล ความต้องการทั้งเชิงธุรกิจและไม่ใช่เชิงธุรกิจ(requirement) ครบถ้วนสมบูรณ์ 100% ได้ตั้งเเต่เริ่มทำหรือก่อนทำโปรเจค
2. ทุกความต้องการที่คุณรวบรวมมาได้ แน่นอนว่าวันหนึ่งมันจะเปลี่ยน สิ่งที่เคยจริงหรือถูกต้องจะไม่จริงและไม่ถูกต้องอีกต่อไป
3. สิ่งที่อยากทำ(TODO)มักจะมีมากเกินกว่าเวลาและเงิน หรือทรัพยากรจัดสรรให้เสมอ

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

ถ้าหากว่ามันต้องเป็นเช่นนั้นแล(3 Known contraints/truth) ฉันจะอยู่กับมันอย่างไรให้ชีวิตฉันมันดีย์ที่สุด(Solution)?

กลุ่มผู้สร้าง Agile เค้าให้คำแนะนำอย่างไรบ้างนะะ

Truth#1 — เป็นไปไม่ได้เลยที่จะรวบรวมข้อมูล ความต้องการทั้งเชิงธุรกิจและไม่ใช่เชิงธุรกิจ(requirement) ครบถ้วนสมบูรณ์ 100% ได้ตั้งเเต่เริ่มทำหรือก่อนทำโปรเจค

“การทำ Analysis หนักหน่วงเป็นเวลา 6 เดือน หรือจะสู้ทำ Analysis 2 เดือนและอีก 4 เดือนให้เวลากับการทำโปรเจคจริงเลย เริ่มส่งของทดสอบกับลูกค้าจริงในตลาดเล็กๆ ได้สามรอบ และทุกครั้งที่ส่งมอบจงเก็บฟีตแบคจากลูกค้า(user feedback)สม่ำเสมอและนำมาเป็นไอเดียในการพัฒนาและส่งมอบของในรอบถัดไป”

https://i0.wp.com/www.inspectandadapt.de/wp-content/uploads/2019/10/72D67175-6580-4CFC-8963-0F70DBFFA4C5.jpeg?fit=1200%2C594&ssl=1

ถ้าเรามัวแต่รอเก็บข้อมูล 100% ฟันธงโปรเจคนี้หม่ายตั้งแต่ยังไม่ได้เริ่มทำแน่นอน มีหรอที่เราจะรวบรวมความต้องการได้ 100% อะไรคือเกณฑ์ที่สามารถใช้บอกได้ว่า 100% แล้ว? โดยเฉพาะในยุคปัจจุบันที่ความต้องการทางตลาด(market need)เปลี่ยนแปลงตลอดและเปลี่ยนแปลงบ่อย(Disrupt) คนที่หยุดพัฒนาแล้วเท่านั้นที่มองว่าความต้องการที่ตนรวบรวมมานั้นครบแล้ว 100% ไม่มีเพิ่มเติมอีกแล้ว ดังนั้นอย่ารอค่ะ อย่ารอให้ถึง 100% โดยเฉพาะเมื่อมีความเสี่ยงที่เกิดขึ้นจากการเริ่มทำหรือเริ่มตัดสินใจทำช้า(Risk of delay) เหมือนที่ Colin Powell อดีตรัฐมนตรีว่าการกระทรวงการต่างประเทศสหรัฐที่กล่าวไว้ใน “The 40–70 rule of decision-making”[1] ว่า

“จังหวะการตัดสินใจที่เหมาะสมควรทำในตอนที่เราข้อมูลเพียง 40–70%”

และเมื่อโปรเจคเริ่มเดินระหว่างทำให้หมั่นเก็บฟีตแบคจากลูกค้าบ่อยๆและสม่ำเสมอ(user feedback) จะเก็บฟีตเเบคจากลูกค้าบ่อยๆได้ต้องเกิดจากส่งมอบของให้ลูกค้าชิ้นเล็กลงแต่บ่อยขึ้น

โดย user feedback นี้เองคือหัวใจสำคัญที่นำมาปรุงแต่งให้โปรเจคเราตอบรับกับความต้องการของลูกค้าให้กลมกล่อมมากขึ้น เพราะมันได้มาจากการใช้งานผลิตภัณฑ์(product)ของโปรเจคจริง ซึ่งถ้าเราไม่เริ่มทำโปรเจคเพราะมัวแต่เก็บความต้องการของโปรเจคให้ครบก่อนข้อมูลส่วนนี้จะไม่มีวันได้รับรู้เลย และผลพลอยได้สุดท้ายคือ user feedback สามารถเป็นส่วนผสมสำคัญที่ช่วยให้ทีมเป็นทีม ทีมที่ไม่ใช่แค่การรวมตัวของกลุ่มคน ทีมที่มีเป้าหมายเดียวกัน ทีมที่รู้ว่ากำลังทำอะไร และทำเพื่อใคร ไปช่วยให้ลูกค้ามีชีวติที่ดีขึ้นอย่างไร สิ่งที่เราช่วยกันสร้างไปถึงมือและให้คุณค่ากับลูกค้าได้จริงไหม

“คุณอยากได้กลุ่มคนที่ทำงานแค่เงิน หรือทีมที่มีวิสัยทัศน์ เข้าใจลูกค้าถ่องแท้พร้อมถวายเวลา 8 ชมต่อวัน 5 วันต่อสัปดาห์เพื่อส่งมอบคุณค่าให้กับลูกค้าอย่างสม่ำเสมอ สร้าง Motivated team”

https://www.drjimtaylor.com/4.0/wp-content/uploads/2020/09/fear-of-failure.jpg

ดังนั้น

“จงเริ่มเลย อย่ากลัวจนไม่ได้ทำอะไร อะไรที่ทำแล้วงานเดิน เดินผิดบ้างถูกบ้างอย่างน้อยพอมองย้อนกลับเราก็มาไกลจากเมื่อสัปดาห์ จากเดือนก่อนถึงว่าเป็นการเรียนรู้ที่พิสูจน์แล้ว(Validated learning) ซึ่งคุ้มค่า แม้การเรียนรู้ ลองผิดลองถูกจะไม่สามารถใช้จ่าย หรือนำไปฝากในธนาคารได้ แต่การเรียนรู้ใดๆที่บอกได้ว่าองค์ประกอบใดที่ใช้ได้หรือใช้ไม่ได้ เพื่อมุ่งหน้าไปสู่สิ่งที่ยั้งยืนในระยะยาวย่อมคุ้มค่าเสมอ”

— The Lean startup[2]

Author note

เขียนเพลินเลยค่ะรู้ตัวอีกทีก็เป็นบล๊อคที่ยาวอีกแล้ว สำหรับสิ่งที่กลุ่มผู้สร้าง Agile กล่าวไว้สำหรับ Trust#2 และ #3 ขออนุญาตตัดเนื้อหาไป part2 นะคะ หากมีคำติชมหรือแนะนำ สามารถคอมเมนต์ด้านล่างได้เลยนะคะ ยินดีค่ะ

สำหรับคนที่อยากไปศึกษาเพิ่มเติม เนื้อหาในบล๊อคนี้มาจากประสบการณ์การทำงานของตัวแอนเองในสภาพแวดล้อมการทำงานแบบ Agile นานกว่า 5 ปีบวกกับเนื้อหาหนังสือหลายๆเล่ม แต่ถ้ามีเวลาไม่มากแนะนำเลยค่ะ 2 เล่มนี้กับ 1 course

• Agile samurai[3]
• the lean startup[4]
• Easy steps with Agile by ทวิร พานิชสมบัติ (รูฟ) [5]

แล้วทุกคนจะมอง Agile ไม่เหมือนเดิม

One last little fun fact

https://www.thekua.com/atwork/2018/07/flavours-of-agile/

Agile เกิดจากการนำกลุ่มคนหลายๆกลุ่มที่คิดค้น และเชื่อใน Development methodology/framework ที่แตกต่างกัน ไม่ว่าจะเป็น

• Crystal,
• scrum,
• Lean,
• Extreme programming(XP),
• kanban
• etc

มารวมตัวกัน มานั่งคิดนอนคิดเพื่อกลั่นความเชื่อร่วม(Believe)ระหว่างหลากหลาย Methodology หรือ Agile ออกมา ดังนั้น Agile จึงเป็นเสมือน Core principle หลักที่ 5 methodology ด้านบนเห็นพ้องต้องกัน โดย 5 methodology นี้เป็นสิ่งที่ถูกนิยามขึ้นก่อนแล้วจึงมาหาความเชื่อร่วมซึ่งเป็น Agile ในภายหลัง

แต่แต่แต่ มุมการนำไปใช้จริงคุณไม่จำเป็นต้องเลือก Methodology อย่างใดอย่างหนึ่ง คุณสามารถเริ่มจากลองใช้ของบางอย่างจาก Scrum framework ถ้ามันเวิร์คก็ทำต่อ ไม่เวิร์คก็เททิ้ง(กล้าที่จะบอกลากับสิ่งหรือคนที่ไม่ใช่ สำหรับผู้ที่สนใจแนะนำอ่านเพิ่มเติมได้ที่ลิ้งนี้เลยค่ะ อีกหนึ่ง Masterpiece จากพี่รูฟ //อีกแล้ววว) หรือลองผสมบางอย่างจาก XP หรือ framework อื่นดูบ้างเพื่อ “สร้าง Methodology ที่เข้ากับจริตของทีมหรือบริษัทคุณมากที่สุด” นี่คือสิ่งที่สำคัญที่สุด