Agile,Coach,Facilitator Skill,Pitfalls

ตกมาเยอะเจ็บมาแยะ : My Pitfalls – Part I

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

A rusty old bear trap with a strong shadow. Very high resolution 3D render.

image credit
http://www.ldinet.org/2008/images/stories/suduced%20by%20success.jpg

ผมมีความรู้สึกว่าถ้าจะเล่า Pitfall ของผมเองให้เข้าใจได้ง่ายก็น่าจะเล่าเป็นลำดับเหตุการณ์จากที่ผมพยายามลองเอาอไจล์มาใช้กับทีมที่ผมเคยดูแล ซึ่งถึงตอนนี้ทีมที่ผมดูแลอยู่ก็ไม่ได้จะคล่องตัวมาก คุณภาพงานไม่ได้ถึงขนาด perfect การใช้ engineering practices ต่าง ๆ น้อย รวมถึงทีมงานจะไม่ self-managed กันเต็มร้อยแบบที่เขาบอกกัน แต่หลังจากผ่านมาหลายปี มันก็มาถึงจุดที่สามารถภูมิใจได้ว่า เราก็ผ่านการล้มลุกคลุกคลาน ร่วมด้วยช่วยกันมาจนถึงจุดที่สามารถภูมิใจในตัวเองได้ระดับนึง แต่ถ้ามองย้อนกลับไปที่จุดเริ่มต้น ในวันที่ผมสนใจในอไจล์แล้วพยายามเอาเข้ามาใช้มันก็เริ่มจากที่ผมไป Training เนี่ยแหละ

Pitfall 1 : Training มาแล้วทำได้เลย

เหตุมันเกิดจากที่มีพีคนนึงในกลุ่ม Team Lead สนใจในการลองเอา Scrum มาใช้กับทีมบ้าง (ผมก็อยู่ในกลุ่ม Team Lead ด้วยในตอนนั้น) ซึ่งแน่นอนว่าในช่วงเวลานั้นผมเริ่มเข้าไปจอยใน Facebook Group agile๖๖ และได้มีโอกาสทำความรู้จักคำว่า Scrum บ้างแล้ว และแอบไปเห็นว่ามี่ Class Training เกี่ยวกับ Scrum (Training + Workshop 2 วัน) ที่เปิดโดย Software Park อยู่พอดี จึงคุยกันว่าให้พี่ที่สนใจลองได้ไปเรียน แล้วเอากลับมาลองใช้กับทีมดู ซึ่งแน่นอนว่าคนที่ไปเรียนก็เหมือนจะไฟลุก มีไฟในการที่จะลองทำลองใช้กลับมาก็เอาหลักสูตรมาสอนน้อง ๆ ทุกคน จัดกลุ่ม Training แล้วก็เริ่มลงมือใช้ Scrum กันเลย ซึ่งก็แน่นนอนเพื่อให้ครบกับ Role ที่ Scrum ประกาศไว้ พี่ ๆ ที่เป็น Team Lead ก็อนุมานตัวเองให้เป็น Product Owner และ ScrumMaster กันอย่างสนุกสนาน จาก Training 2 วัน จากสถานการณ์ที่ถูก Fix ถูกสร้างให้ไม่มีผลกระทบกับงาน มากลายเป็นงานจริง ๆ ที่มีทั้งแรงกดดัน มีทั้งความเข้าใจ ในช่วงแรกเราจึงเดินกันแบบมั่ว ๆ ทำเฉพาะในส่วนที่เราเข้าใจ และทำได้ ส่วนตัวผมเองที่อุปโลกน์ตัวเองเป็น ScrumMaster ก็ไม่ได้เข้าใจ Scrum ไม่รู้ว่า Value ของการทำงานแบบนี้สักเท่าไหร่ จนมีหลาย ๆ ครั้งที่เราคุยกันว่า เรากลับไปทำงานแบบเดิมไหม การทำงานแบบนี้ไม่น่าจะเหมาะกับเรานะ

My Experiment

จริง ๆ แล้วสิ่งที่เกิดขึ้น ไม่ได้หมายความว่าการไปเรียนรู้ในสิ่งต่าง ๆ เพื่อเอามาปรับใช้กับการทำงานของเราเป็นเรื่องไม่ดีนะครับ มันเป็นสิ่งที่ควรทำด้วยซ้ำ แต่สิ่งที่อยากจะบอกคือ การจะลงมือทำอะไรใน Domain ที่ตัวเองไม่ถนัด อาจจะต้องทำการศึกษา ทดลอง หรือรวมไปถึงการหาที่ปรึกษาที่รู้เรื่องมาพาทำ เพื่อให้เขาช่วยประคับประคองให้เราไปในทางที่ไม่หลงไปจากวัตถุประสงค์หลักของมันมากเกินไป ในตอนนั้นเองผมก็พยายามที่จะเข้าไป Join ในกลุ่มทำงานต่าง ๆ ที่เขาเคยใช้ Scrum เพื่อหาโอกาสซักถามในข้อสงสัย ซึ่งหลาย ๆ ครั้งมักจะมีคำถามกลับมาว่าเราทำมันไปทำไม เพราะฉะนั้นก่อนจะเริ่มทำอะไรลองตั้งคำถามกับตัวเองครับ ถามตัวเองเลยว่าทำไมต้องทำแบบนั้น ? ทำไม ?

Pitfall 2 : อุปโลกน์คนที่รู้ Requirement มากที่สุดในทีมมาเป็น Product Owner

แน่นอนว่าใน Scrum เขาบอกว่าต้องมี Role ต่าง ๆ อยู่ 3 Role คือ ScrumMaster, Team และ Product Owner มาถึงจุดนี้เราเข้าใจไปว่า Product Owner คือเจ้าของ Product คือคนที่รู้จัก Product มากที่สุด หันไปหันมาเราจึงหันไปเจอว่าในทีมที่เราทำงานอยู่คนที่รู้ Business Requirement มากที่สุด น่าจะรู้ว่าอะไรเป็นอะไร เราจึงอุปโลกน์พี่ Team Lead คนนึงซึ่งทำหน้าที่เป็น System Analyst มาก่อน มาเป็น Product Owner ของเรา แน่นอนว่ามันก็พอจะเป็นไปได้ แต่สิ่งที่เราพลาดคือ Product Owner จริง ๆ ไม่ได้เป็นคนที่ทำหน้าที่เคลียร์ Requirement แต่หน้าที่หลักของเขาคือนักลงทุน เขาคือคนที่มองว่าควรจะลงทุนกับอะไร เป็นคนที่รู้ว่าจะเอาเวลาของ Team ไปลงทุนกับ Feature ไหน ลงทุนเพื่อสร้างประโยชน์สูงสุดกลับมากจาก Product ที่กำลังทำอยู่ ส่วนหน้าที่ Clear Requirement ให้เป็นหน้าที่ของทีมงานของ Product Owner ที่จะหาข้อมูลต่าง ๆ เพื่อส่งให้ PO ได้ตัดสินใจได้อย่างถูกต้อง การที่เราอุปโลกน์ System Analyst มาเป็น Product Owner ในตอนนั้นจึงเป็นจุดผิดพลาดที่เกิดขึ้น ไม่ใช่ว่าเขาทำหน้าที่นั้นไม่ได้ เขายังสามารถทำหน้าที่บางอย่างได้ แต่เพราะเขาไม่ได้มีอำนาจในการตัดสินใจเลือก Feature ที่สำคัญจริง ๆ เขายังเป็นเพียง IT Guy ซึ่งเอา Requirement จากลูกค้ามาส่งต่อให้กับทีม รวมไปถึงตัวเขาเองไม่ได้มองไปถึงจุดของการลงทุน ไม่ได้มองไปถึง Value ของ Feature ที่กำลังสร้าง ซึ่งตอนนั้นผมเองในฐานะ ScrumMaster ก็ไม่ได้เข้าใจอะไรปล่อยให้เหตุการณ์แบบนี้ดำเนินต่อไปอย่างยาวนาน

Pitfall 3 : ลูกค้า (Product Owner) ต้องรู้ทุกอย่าง

หลังจากเริ่มทำงานมาได้ระยะนึงก็เริ่มเกิดปัญหาที่มามอง ๆ ทีหลังนี่ก็เริ่มรู้สึกว่ามันเป็นปัญหาปกติที่เกิดขึ้นกับหลาย ๆ ที่ ปัญหาที่ว่านี้คือ “Requirement ไม่ชัดเจน” ซึ่งแน่นอนว่าทั้งหมที่ทำหน้าที่ ScrumMaster ทั้งทีม Dev ก็โบยกลับไปที่คนที่ทำหน้าที่เกี่ยวกับ Requirement นั่นก็คือ Product Owner ที่เราอุปโลกน์ขึ้นมาทันทันที เราจึงเริ่มสร้างกำแพงที่เรียกว่า Requirement ที่ชัดเจน ระหว่างทีม Dev กับ Product Owner โดยสร้างข้อกำหนดว่า Product Owner ต้องเขียน Requirement มาให้ชัด ๆ ว่าจะให้ทีม Dev ทำอะไร บ้าจนถึงขนาดที่ให้บอกมาเลยว่า มี Field ไหนที่ Require Field ไหนที่ เป็น Optional แล้วปล่อยให้ PO ไปคุยกับลูกค้าให้ชัดเจนก่อนที่จะมาบอกให้ทีม Dev ทำอะไร แถมเวลาที่ PO ของปรับอะไรบางอย่างก็จะ Feedback กลับไปแรง ๆ ว่าอย่ามาเปลี่ยน Requirement สิ ช่วงนั้นถือได้ว่าเป็นช่วงมืดของทีมเลยทีเดียว PO ก็ไม่รู้ว่าจะทำงานยังไงถึงจะถูก ทีม Dev ก็ไม่ได้เข้าใจความต้องการจริง ๆ ของลูกค้าดูแต่จาก Spec ที่ PO กำหนดให้ทำ ซึ่งแน่นอนว่าขัดกับหลักการของอไจล์อย่างชัดเจน ไม่ว่าจะเป็น Customer collaboration over contract negotiation หรือ Responding to change over following a plan ทั้ง ๆ ที่ Scrum บอกว่าหน้าที่อีกอย่างของ PO คือการทำให้ Team และ Customer ได้ทำงานร่วมกัน เข้าใจกัน Team จะได้รู้ที่มาที่ไปของ Requirement รู้ว่าอะไรคือสิ่งสำคัญที่ลูกค้ามอง Team จะได้รู้ว่าอะไรคือส่วนที่ต้องป้องกันไม่ให้เกิดปัญหาตอนที่ เอาไปใช้งานจริง ซึ่งผมเองในตอนนั้นในฐานะ ScrumMaster กลับเป็นส่วนนึงที่ทำให้ Team กับ Customer ทำงานห่างกันมายิงขึ้น ๆ ไปอีก

Pitfall 4 : รอ Demo งานกับ Product Owner 

บางคนอาจจะรู้สึกว่า เอ๋ … การ Demo งานกับ Product Owner ก็เป็นเรื่องปกตินี่นา จริง ๆ แล้วเป็นสิ่งที่ผมเข้าใจผิดต่อมาจาก PO ต้องรู้ทุกเรื่อง เนื่องจากความเข้าใจว่า PO กับ Team ทำงานกันคนละส่วน และกังวลว่า PO จะเข้ามา Interrupt งานที่ทีมทำอยู่แล้วทำให้งานไม่เสร็จตามเวลาของ Sprint เลยพยายาม กัน PO ออกจากทีม แล้วให้ไปดูงานกันเลยทีเดียวตอน Sprint Reviews ซึ่ง Scrum บอกว่านั่นคือจุดที่เราจะได้แสดงสิ่งที่เราทำมาทั้ง Sprint ปัญหามันก็เกิดขึ้น เพราะช่วงเวลาใน Sprint Team มีคำถามจะถามอะไร ก็เหมือนจะไม่กล้าถามเพราะทำตาม Requirement ที่ให้มาตามนั้นก่อน ทั้ง ๆ ที่บางอย่างมันอาจจะดูไม่ปกติ บางส่วน PO อยากจะคุยกับทีมเพื่อเช็คความเข้าใจ อยากจะทำให้งานมันออกมาถูกต้องก็ไม่ได้ กลายเป็นแทนที่จะได้คุยกัน ได้ปรบให้ถูกต้อง ต้องมารอเวลา Sprint Reviews หลังจากที่ทำมาสักพัก ได้ถามผู้รู้จึงได้รู้ว่า สิ่งที่ดีที่สุดที่ควรเกิดขึ้นคือ PO กับ Team ทำงานร่วมกันตลอดเวลา Team ทำเสร็จก็ให PO ดูเลย ได้ Feedback เลย แล้วค่อยมาช่วยกันประเมิณว่า Feedback นั้น จะสามารถปรับแก้ได้เลยไหม หรือควรจะเอาไปปรับปรุงกันในรอบต่อ ๆ ไปให้เขาได้คุยกัน แลกเปลี่ยนความคิดเห็นกัน สร้างความเชื่อใจในกันและกัน แล้วถามว่า ถ้า PO กับ Team ทำงานร่วมกันแบบนั้น ได้เห็น Product ตลอดเวลาแบบนั้น แล้วจะมี Sprint Reviews ไว้ทำไม ซึ่งนั่นก็เป็นอีกความเข้าใจผิดของผมเหมือนกัน จริง ๆ Sprint Reviews คือการเอา Product ที่ PO เลือกให้เข้ามาใน Sprint และทำเสร็จเอาไปให้ Stakeholder ทั้งหลายได้ดู เพื่อโชว์วิศัยทัศน์ของ Product Owner ที่จะทำเพื่อตอบโจทย์ปัญหาของ Stakeholder ทั้ง ๆ เพื่อให้เขาเหล่านั้นได้เห็นทิศทาง ประโยชน์และเอา Feedback จาก Stakeholder ทั้งหลายมาปรับปรุง Product ให้ดียิ่ง ๆ ขึ้นไปอีก

Pitfall 5 : ทำ Software กองไว้ รอส่ง QC (ยังไม่มี QC)

ในช่วงแรกของการทำงานแบบ Scrum เนื่องจากเป็นการอยากลองของพี่ ๆ Team Lead เอง ซึ่งในตอนนั้นยังไม่รู้ว่า Concept นี้จะ Work หรือไม่ เราจึงสร้าง Scrum Team ที่มีแต่ Developer ส่วน Process การทำงานก็จบประมาณ Dev เทสกันเองแบบ Dev ๆ แลกกันทำแลกกัน Test โดยส่วนของนอกทีม Scrum ยังเป็น Waterfall Project ธรรมดา แน่นอนว่า Feature ต่าง ๆ ที่เราทำทั้งหมดถูกเทสด้วยความเข้าใจแบบ Dev ๆ ลอง ๆ จิ้มดูถ้าไม่ Error ก็ถือว่า OK (ปกติเขาทำกันแบบนี้ไหมนะ อายจัง) แล้วก็กองรอเวลา จนถึง Phase Test ค่อยส่ง Feature ทั้งหมดที่เราคิดกันว่าทำเสร็จแล้วไปให้ Tester ผลลัพท์ที่ได้ก็น่าจะเดาออก Defect เต็มไปหมด เรื่องนั้นที่หน้านนั้นทำแบบนี้ แต่หน้านี้ทำแบบนั้น ข้อมูลที่มาจากหน้านั้น ไม่สามารถเอาไปใช้ได้ในหน้านี้ กลายเป็นต้องมานั่งต่อรองกันว่าอันไหนเป็น Defect อันไหนไม่เป็น Defect เกิดสงครามขึ้นระหว่าง Dev กับ Tester แทนที่เราจะเอาประโยชน์จากการทำงานในรอบสั้น ๆ เพื่อให้ได้ Feedback เอามาหาทิศทางที่ถูกต้องในการเดินต่อ ได้เรียนรู้ข้อผิดพลาดของตัวเองจาก Defect เพื่อไม่ให้เดินซ้ำรอยเดิม แทนที่เราจะพยายามทำงานร่วมกันกับ Tester กับกลายเป็น Phase ๆ เหมือนเดิม หลังจากที่เรารู้ปัญหาเราจึงค่อย ๆ เริ่มปรับวิธีการทำงานร่วมกับ Tester โดยการส่งของเป็นรอบ ๆ คุยกับ Tester มากขึ้น ให้เขาช่วย Test หลังจากที่เราทำเสร็จ (Sprint ของ Dev กับ Sprint ของ Tester) จนสุดท้ายเราก็สามารถ Invite Tester เข้ามาอยู่ใน Scrum Team ของเราได้

ลองหาเส้นทาง Pitfalls ของตัวเองดูครับ

มาถึงตรงนี้รู้สึกว่าจะเหนื่อยมากแล้ว ขอพอแค่นี้ก่อน จริง ๆ ยังมีอีกหลาย ๆ อย่างที่ผมเจอแล้วทำไปอย่างไม่เข้าใจ จนได้ผลลัพท์ที่ไม่ดีกลับมา ซึ่งถ้ามีโอกาสผมคงได้มาเล่าใน My Pitfalls – Part II อีกทีครับ แต่อย่างไรก็ดีอย่าเชื่อในสิ่งที่ผมเล่าไปทั้งหมด ลองพิจารณาดูว่าสิ่งที่ตัวเองเจออยู่เป็นแบบเดียวกับผมไหม บางทีเหตุการณ์เดียวกันสถานการณ์เดียวกัน แต่เวลาเปลี่ยนผลของมันก็อาจจะไม่เหมือนกันก็ได้ เพราะฉะนั้นสิ่งที่คุณทำอยู่ถึงจะเป็นสถานการณ์เดียวกับผม ก็อาจจะได้ผลลัพท์ไม่เหมือนกันกับผมก็ได้ สิ่งที่จำเป็นจริง ๆ ในการที่จะทำให้รู้ตัวเองได้ว่ากำลังอยู่ผิดทางไหม คือการกลับไปดู Agile Manifesto แล้วถามตัวเองว่า เรากำลังให้ Value กับด้านซ้าย หรือขวามากกว่ากัน และสิ่งที่สำคัญที่สุดคือ

จงเชื่อในการลงมือทำ เรียนรู้ และหาเส้นทางที่เป็นของตัวเอง

No Pain No Gain

 

Advertisements

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s