Scrum Mislead
จากประสบการณ์ที่ผมได้ไปทำงานกับลูกค้าหลายๆ ราย ที่ใช้ Scrum ผมมักจะพบเรื่องที่เค้าให้ความสำคัญมากเกินไป จนลืม หรือมองข้ามสิ่งที่ต้องให้ความสำคัญจริงๆ เรามาดูกันครับว่ามีเรื่องอะไรบ้าง
แต่ก่อนที่จะไปดูในรายละเอียด ผมอยากให้กลับมาดูแนวคิดหลักของ Agile software development ก่อนครับ ลองดูตารางนี้กัน ประมาณว่ามีการ break down ออกมาแล้วว่าต้องมี feature อะไรบ้าง แต่ละ feature ก็จะประกอบด้วยขั้นตอนการพัฒนา software อย่างที่เราคุ้นเคยกัน แบบนี้
ถ้าเป็น Waterfall เราก็จะเตรียมงานตาม process คือ ทำ requirement ให้เสร็จก่อน แล้วไป design จากนั้นก็เอาไปเขียนโปรแกรม ไปเรื่อยๆจนเสร็จ แบบนี้
Highlight สีฟ้าคือ effort ที่ทำ ผลลัพธ์ที่ได้ก็มันจะ focus ที่เอกสาร เช่น Requirement Specification, System / Software Design, Source code / Binary, Test cases. etc.
แต่ถ้าเป็น Agile (iterative & incremental) ก็จะเปลี่ยนเป็นทำทุกอย่าง แต่ทำทีละ feature ตาม value ของ feature แทน ทำเสร็จมากพอที่จะ release ก็ release เลยโดยที่ไม่ต้องทำให้เสร็จหมดก็ได้ แบบนี้
ผลลัพธ์ที่ได้ในแต่ละ feature ก็คือ software incremental ที่ทำงานได้จริงภายใต้ scope ของ feature นั้นๆ
ซึ่งถ้ามองให้ลึกลงไปถึงวัตถุประสงค์ของการทำแบบนี้ ก็เพื่อให้เราสามารถ focus ไปที่ feature ที่มีคุณค่าสูงสุดก่อน ถ้าในระหว่างทางมีอะไรเปลี่ยนไป เราจะได้กลับตัวได้ง่ายเมื่อเทียบกับการทำแบบเดิม
อย่างไรก็ดี ถ้าเราให้ความสำคัญกับการทำให้ถูกวิธี เราจะหลงลืมวัตถุประสงค์ไป ลองมาดูกันครับว่าปัญหาอะไรบ้างที่ผมมักจะเจอเป็นประจำเลย
1. Purpose vs. Process
บ่อยครั้งที่ทีมเปลี่ยนการทำงานเป็น Scrum ทุกคนจะ focus กับ process กัน เช่น Sprint ต้องมี event อะไรบ้าง, ใครต้องทำอะไร, ทำแค่ไหน, BA เคยทำแบบนี้ ต่อไปทำยังไง เป็นต้น ซึ่งก็เป็นเรื่องปกติของการเปลี่ยนวิธีการทำงานที่ช่วงแรกๆมันจะขัดๆ งงๆ ไปหมด (ถ้าไม่งงแสดงว่าน่าจะทำเหมือนเดิมนะ) อย่างไรก็ดี พอทำไปสักระยะหนึ่ง ทุกคนกลับตกหลุมพราง คือไปให้ความสำคัญกับ process โดยหลงลืมวัตถุประสงค์ไปว่า ทำไมต้องทำแบบนั้น เช่น ทำไมต้อง Planning, ทำไมต้อง Daily, etc. แล้วกลายเป็นไปยึดวิธีการเหล่านั้น บ่อยครั้งมันก็นำมาซึ่งปัญหาใหม่ แต่ก็ไม่ได้เข้าใจวัตถุประสงค์ แต่ก็ไม่ยอมเปลี่ยนวิธีการ เช่น ทีมเบื่อ daily scrum มาก ถามตอบทุกวันว่า เมื่อวานทำอะไร วันนี้จะทำอะไร ไม่มีปัญหาอะไร ไม่มีใครรู้ว่าใครทำอะไร แล้วก็ไม่รู้จะพูดไปทำไม เป็นต้น พอทำไปแล้วหลายๆอย่างเป็นแบบนี้ ก็จะบอกว่า Scrum ไม่ work
กลับไปดูวัตถุประสงค์ (purpose) ครับ ว่าแต่ละเรื่องมีวัตถุประสงค์อะไร เราพยายามแก้ปัญหาอะไร ทำแล้วมันให้คุณค่า (value) อะไร เมื่อเข้าใจแล้วก็ปรับการทำงานให้ดีกว่าเดิมครับ
2. Practice vs. Process
เรื่องถัดมาที่เจอบ่อยพอๆกัน คือ พอเปลี่ยนการทำงานเป็น Scrum ทุกคนลืมหมดเลยว่า practice การทำ software ที่ดีต้องทำอะไรบ้าง ทั้ง requirement, design, develop (ที่ดี), test, deploy คือไปให้ความสำคัญกับ process และ ceremony แต่ลืม practice ไปหมดเลยว่า อะไรที่สำคัญก็หายไปหมดเลย ที่เจอบ่อยเลยคือเรื่องเอกสาร
แม้ว่าเราจะค่อยๆ ทำไปทีละ feature ก็ไม่ได้แปลว่าเราไม่ต้องทำเอกสารนะ แต่เอกสารที่ทำจะทำเฉพาะส่วนที่สำคัญจริงๆ และได้ใช้ เช่น business logic บางอย่างที่รายละเอียดเยอะ ถ้าไปอ่าน code มันก็ไล่ยาก สื่อสารกับ stakeholder ก็ยาก เหตุการณ์ที่ผมพบบ่อยๆคือ ทีมเคยคุยกันแล้วจดไว้บน online tool ซักที่นึง เมื่อเวลาผ่านไปก็พบว่า scenario มันไม่ครบ จังหวะนี้แหละที่ไม่มีใครจำได้แล้ว อย่าว่าแต่ logic เป็นยังไงเลย จดไว้ที่ไหนยังจำไม่ได้เลย (หวังว่าใน code และ unit test จะสะท้อน business logic นั้นได้นะ)
อีกหนึ่งตัวอย่างที่ทีมมักจะมองข้าม ก็คือเรื่อง Design Decision บ่อยครั้งที่ทีมต้องเลือก architecture หรือ design แบบใดแบบหนึ่ง ที่มันก็ดีทั้งคู่ แต่ design ที่เลือกมันเหมาะสมกว่าทั้งๆที่มันอาจจะไม่ make sense เลยถ้ามองจากสายตาคนภายนอก เอกสารที่เหมาะที่จะบันทึกเรื่องแบบนี้ก็คือ ADR หรือ Architectureal Decision Record (https://adr.github.io/) ที่จะบันทึกว่า การตัดสินใจเลือก Architecture แบบนั้น มากจากเหตุผลหรือข้อจำกัดอะไร ผลที่ตามมา (consequence) คืออะไร ถ้าเปลี่ยนไปอีกแบบจะมีปัญหาอะไร จึงเลือกแบบนี้ เป็นต้น
เพราะฉะนั้น เราไม่จำเป็นต้องโยน skill, tools, หรือ knowledge ในอดีตทิ้งไปเพียงเพราะเราเปลี่ยนไปใช้ Scrum นะ ถ้าจุดไหนใช้ UML Diagram หรือ C4 Model อธิบายแล้วเห็นภาพก็ใช้ การทำ Test Case เพื่อทำ test automate มันก็ต้องใช้ knowledge การทำ manual test เหมือนเดิม เช่น edge case, negative case, wrong data type input, etc, หรือถ้าจำเป็นต้องมี Requirement Specification ก็ทยอยทำไปทุก sprint ได้ ถ้าบอกได้ว่ามันเอาไปใช้ประโยชน์ยังไง
3. Skill vs. Role
อีกเรื่องคือ role & responsibility เคสที่ผมปวดหัวที่สุดน่าจะเป็นเรื่องคน คือ เมื่อเปลี่ยนการทำงานเป็น Scrum ทุกคนพยายามปรับการทำงานให้เป็น cross-functional team ซึ่งในช่วงแรกๆ ก็จะขาดๆเกินๆ ซึ่งก็ไม่ได้ผิดอะไรนะ ดีแล้วแต่เมื่อผ่านไปช่วงนึง กลับกลายเป็นว่าบางคน lack of responsibility แทน เช่น เคยเป็น team leader ที่ก่อนหน้านี้เคยทำ software specification document แล้วส่งต่อให้ developer ทำงาน พอเปลี่ยนการทำงานเป็นแบบ Scrum ก็เลยห้ามทำเองคนเดียว เดี๋ยวจะแย่ง ownership จากทีม ต้องให้ทั้งทีมทำ และ … ปล่อยจอย … อ่า … 🤦🏻
Agile Core Values & Principles
สำหรับผมแล้ว ตัวอย่างที่ยกมา น่าจะเป็นเพราะแยกไม่ออก ระหว่าง วัตถุประสงค์ กับ วิธีการ คือไม่เข้าใจและแยกไม่ออกว่า อะไรกันแน่คือสิ่งที่ต้องให้ความสำคัญ แล้วเลือกทำตามวิธีการที่ดูเหมือนถูกแต่เกิดปัญหาใหม่ตามมาแทน
ถ้ากลับไปอ่าน Agile Manifesto เราก็จะเห็นเรื่องเหล่านี้อยู่ในทุกๆข้อของ core values และ principles นะ แน่นอนว่าในช่วงแรก ทีมที่นำ Scrum (หรือ Agile methodology อื่นๆ) มาใช้ ก็จะเจออะไรที่คล้ายๆกัน ถ้าไม่สามารถกลับมาอยู่ใน track ที่ถูกต้องก็มักจะจบลงที่การเลิกทำ แล้วบอกว่า Scrum / Agile ไม่ work เลย
ก็อยากให้ลองฉุกคิดแล้วกลับมามองที่ทีมของเราเองครับ ว่าตัวเราเองหรือเพื่อนๆของเราทำทำงานด้วยกันเป็นแบบนี้ไหม ถ้าใช่ ก็เป็นจังหวะที่ดีที่จะได้เอาไปคุยกันใน Sprint Retrospective เพื่อให้เกิด continuous improvement จริงๆ
Book
ก่อนจบ ผมแนะนำหนังสือเล่มนี้ครับ Zombie Scrum Survival Guide ที่บอกว่า มองไกลๆ เหมือนเป็นทีม Scrum ที่ดีนะ แต่ถ้าเข้าไปดูใกล้ๆ นี่มันซอมบี้นี่ อ่านสนุกดี
https://www.amazon.com/Zombie-Scrum-Survival-Guide-Professional/dp/0136523269
ขอบคุณที่เข้ามาอ่าน, feedback, และแบ่งปันครับ
