Agile,Engineer Pratices,Refinement,Requirement Gathering,Scale,Scrum,Visualization

เมื่อทีมเติบใหญ่ขึ้น – When your team “GROW UP”

เมื่อประมาณสัปดาห์ที่ผ่านมาได้มีโอกาสไปดูงานที่ธนาคารแห่งเก่าแก่นึ่ง ซึ่งได้ลองนำ Agile เข้าไปประยุกต์ใช้กับการสร้าง Product ที่เป็น IT Product ของเขา สำหรับผมที่อยู่ในโลกแคบ ๆ ไม่ค่อยได้ออกไปเปิดหูเปิดตาที่ไหนแล้ว เป็นเรื่องที่น่าสนใจมาก เพราะสิ่งที่เขาพยายามทำมีบางอย่างที่ไม่เหมือนกับที่เราทำอยู่ ถึงแม้แก่นจะมาจากแก่นเดียวกัน แต่ในรายละเอียดแล้ว ก็มีหลายอย่างที่ต่างกัน และแน่นอนว่ามาถึงที่แบบนี้แล้ว จะไม่เดินดูทีม ไม่เดินดูบอร์ด ไม่พูดคุยกับใครต่อใครก็คงจะถือว่าเป็นการเสียโอกาสมาก ๆ หลังจากพูดคุยมาซักครึ่งชั่วโมง ก็มาถึงจุดที่เราคุยกันถึงปัญหาที่เขาเริ่มเจอตอนนี้ คือตอนนี้ทีมเริ่มใหญ่โตขึ้น เขาเริ่มต้องการ Split ทีมออกเป็น 2 ทีม เพราะ Communication Cost ของการที่มีทีมขนาดใหญ่มันเยอะมาก ๆ การเคลื่อนตัวของทีมก็ช้าลงมาก ผมเลยมานั่งคิด ๆ ดูว่าผมเองก็เคยผ่านจุดนั้นมาบ้าง ถึงแม้ทางออกที่ทำไปจะไม่ใช่ทางออกที่ดีนัก แต่ก็ถือโอกาสสรุปไว้ เพื่อวันหลังจะได้ไม่ลืมว่าเส้นทางที่เราเดินมานั้นเป็นอย่างไร

TreeGrowthChart_800x550

credit image http://www.brianvellmure.com/wp-content/uploads/2014/01/TreeGrowthChart_800x550.png

ทำไมทีมต้องใหญ่ขึ้น ?

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

ถ้างั้นเมื่อไหร่ถึงจะต้อง Split Team หรือ Split ยังไงหล่ะ

คำถามแรกนี่ไม่ยากครับจริง ๆ แล้ว Methodology อย่าง Scrum ก็บอกไว้อยู่แล้ว อย่างใน ScrumPrimer ก็บอกว่า The Team ใน Scrum มีขนาดอยู่ที่ 7 บวก/ลบ 2 หรือก็หมายถึง 5 ไม่เกิน 9  ส่วนใน ScrumGuide ก็พูดไว้ที่ 3 ไม่เกิน 9 (อันนี้ก็ขึ้นอยู่กับว่าจะเชื่อตัวเลขนี้ไหมนะครับ 555+) ซึ่งจริง ๆ สุดท้ายจำนวนคนก็ขึ้นอยู่กับทีมสามารถส่งมอบ Ship-able Product ให้กับลูกค้าได้จริง ๆ ในรอบสั้น ๆ หรือเปล่า แต่สำหรับเรื่องที่เราจะคุยกันมันเริ่มน่าสนใจตรงที่ถ้าทีมใหญ่จนเริ่มทำงานไม่คล่องตัวการ Split Team ก็ย่อมเป็นทางเลือกที่ดีทางเลือกนึง ลองดูเลข 9 เป็นตัวบอกร่วมกับความรู้สึกก็ได้ครับ (ของผมนี่ความรู้สึกล้วน ๆ) ถ้าทีมเริ่มทำงานได้ไม่คล่องตัว ทุกคนต้องเสียเวลาไปกับการทำความเข้าใจ การพูดคุยกันใช้เวลานานเพราะจำนวนคนเยอะเกินไปก็อาจจะถึงเวลา Split Team ได้แล้ว ในส่วนของการ Split Team ไม่ว่าจะแบ่งที่ตัวเลขไหนก็ตาม  Team ที่ถูก Split ออกก็ต้องเป็น Team ในบริบทของ Scrum หรือ Agile ไม่ว่าจะต้องเป็น Cross-Functional, Self Managed, Co-Located รวมถึงเป็น Feature Team นะครับ อย่าแบ่งเป็น Component Team เพราะจะทำให้แต่ละทีม Focus เฉพาะส่วนของตัวโดยไมสนใจภาพรวมของทั้ง Product

Split แล้วอะไรบ้างหล่ะที่สำคัญ

จริง ๆ จากประสบการณ์ที่ลองทำนุ่นทำนี่มาหลายแบบ แล้วแต่ละครั้งที่ลองก็ไม่ค่อยได้เก็บอะไรไว้เป็นข้อมูลเท่าไหร่ ก็แค่ลองทำ แล้วก็ดูว่าที่ลองมัน Work ไหม ถ้า Work ก็เดินต่อไปในแนวทางนั้น ถ้าไม่ Work ก็ลองดูว่าจะปรับยังไงต่อได้บ้าง ลองแล้วล้มเหลวมาก็เยอะ ท้อไปบ้างก็มี แต่ก็เดิน ๆ ต่อมาได้ พึ่งมามีช่วงหลังที่มีโอกาสได้ไปเรียน LeSS (Large-Scale Scrum) มา จึงทำให้พอจะเห็นภาพอะไรบางอย่างที่พอจะปรับใช้ได้บ้าง อาจะเป็นเพราะ Class LeSS เน้นว่า LeSS มันคือ Scrum แนวคิดทุกอย่างก็คือ Scrum เพียงแต่พอทีมมันใหญ่ขึ้น มันมีสิ่งที่ต้อง Concern มากขึ้น ยิ่งต้องทำให้เรามาดูว่าแก่นของการทำงานแบบนี้จริง ๆ ควร Focus ที่ไหน ส่วนไหนที่ต้องให้ความสำคัญบ้าง โดยในบทความนี้ผมคงพูดถึงบางส่วนที่ผมพอจะจำได้และ Match กับสิ่งที่ไปคุยมานะครับ ความรู้เพิ่มเติมเรื่อง LeSS สามารถหาอ่านได้จาก http://less.works/ เลย

ถึงจะมีหลายทีม แต่ต้องมี Product Backlog เดียว

many-teams-many-backlogs-one-backlog-agile

http://www.solutionsiq.com/images/many-teams-many-backlogs-one-backlog-agile.png

ในช่วงแรกของการที่ผมลอง Split Team สิ่งที่ทำคือพยายามสร้าง Backlog แยกออกจากกัน ตอนนั้นมองว่าจะได้วางแผนได้ถูกว่าทีมไหนจะให้ทำ Flow Requirement ในส่วนไหน ก็ให้เขา Refine มัน แล้วก็ทำมันอย่างต่อเนื่องด้วยทีมนั้นเอง เพราะถ้าต้องให้ทุกคนเข้าใจ Requirement ทั้งหมดก็จะใช้เวาอีก ซึ่งหลังจากที่ทำมาอยู่พักนึงเริ่มกลายเป็นว่า หลังจากที่เรา Release Software ไปแล้ว ในตอนที่ต้อง Support เกิดปัญหาความเป็น Owner เฉพาะในสิ่งที่ตัวเองทำ (จะว่าเกี่ยงกันก็ไม่เชิง) เริ่มเกิดอาการอันนี้ของทีมนี้ อันนั้นของทีมนั้น แต่ก็เข้าใจได้ ส่วนนึงก็คงเป็นเพราะแต่ละทีมไม่รู้ว่าสิ่งที่อีกทีมทำมามันเป็นยังไง มัน Design ไว้แบบไหน Requirement มันเป็นยังไง ทำให้ไม่รู้ว่าถ้าจะต้องเข้าไปแก้จะต้องทำยังไงบ้างกระทบกับ Flow นั้นในส่วนไหน ความคล่องตัวของทีมเริ่มลดลง กลายเป็นภาพ 2 Team เหมือนจะทำคนละ Product ซึ่งกลายเป็นทีมไหนมี Workload มาก ๆ อีกทีมก็ไม่สามารถเข้ามาช่วยกันได้เลย ผมพยายามกับเรื่องนี้อยูสักพัก แต่ก็ยังหาทางแก้ไม่ได้เพราะกลัวว่า ถ้าจะให้กลับมาคุยเป็นทีมใหญ่ ก็จะเกิดปัญหาเดิม ๆ สุดท้ายได้ไปโดนตบกระบาลที่ Class LeSS มาจึงได้รู้ว่า ไม่ว่าคุณจะมีกี่ทีม ถ้าทำงานด้วยกันบน Product เดียวกัน ก็ความจะมี Backlog แค่ชุดเดียว (ก็มันเป็น Backlog ของ Product นี่นะ ไม่ใช่ Backlog ของทีม) เพื่อให้ทุกคนเห็นภาพความเป็นไปของ Product ด้วยกัน

Product Backlog เดียว ต้องคุยทีมใหญ่อีกไหม ?

พอกลายมาเป็น Backlog เดียว สิ่งสำคัญคือ ตอนทำ Backlog Refinement หรือ Planning เราจะทำยังไงให้ ข้อมูล Flow ไปยังทุกคนในทีม โดยที่ยัง Balanced กับเวลาและ Cost ที่ทุกคนต้องมานั่งคุยกัน จริง ๆ ตอนที่เริ่มมีปัญหา Split Team และเกิดความไม่ Sync กันของ Requirement นั้น ผมก็ไปได้ Technique นึงมาจากจาก Class CSD (Certified Scrum for Developer) ซึ่งสามารถอ่านได้จาก “Collaborating in Refinement” ซึ่งการ Split แล้วเวียนกันนี้ก็เหมาะกับทีมที่มีขนาดใหญ่ไม่มากนัก ซึ่งหลังจากนำไปลองใช้ดูก็สามารถทำให้ทีมเห็นภาพรวมของงานเป็นภาพรวมเดียวกัน แถมลดการใช้เวลาลงได้พอสมควร แต่ก็ยังอาจจะไม่เหมาะกันทีมที่มีขนาดใหญ่มาก ๆ (มากกว่า 2 Scrum Team ก็เยอะมากแล้ว) อีก Technique นึงที่ผมได้เรียนรู้จาก Class LeSS คือการส่งตัวแทนเพื่อคุยภาพรวมของ Feature ที่กำลังจะทำ เพื่อให้ตัวแทนทุกคนเห็นภาพรวมของงานที่กำลังจะเข้ามา แล้วค่อยให้แต่ละทีม รับเอา Backlog Item ที่คิดว่าทีมน่าจะพอทำได้ แยกให้แต่ละทีมไปทำ Sprint Planning โดยให้มี User ของ Feature นั้น ๆ หรือ ตัวแทนงาน Team PO ที่เกี่ยวข้องกับ Feature นั้นไป Confirm ความต้องการในแต่ละทีม แล้วค่อยเอา Feature ทั้งหมดกลับมา Sync กันอีกครั้งก่อนเข้า Sprint ซึ่งผมเองลองเอาแค่บางส่วนมาลองใช้ดูบ้าง แต่เนื่องจากไม่เคยทำงานกับทีมใหญ่ขนาดนั้นจึงไม่สามารถบอกถึงข้อดี/เสีย ได้อย่างเต็มปากนัก ขอแนะนำให้ลองหาข้อมูลเกี่ยวกับการทำ Sprint Planning One และ Sprint Planning Two ของ LeSS ดู ครับ

หลังจากลองมาหลาย ๆ แบบ หลาย ๆ ทางแล้ว สิ่งนึงที่ผมคิดว่าสำคัญมากในการที่จะทำ Backlog Refinement หรือ Sprint Planning สำหรับทีมใหญ่ ๆ หรือการทำทีละหลาย ๆ  Feature Team คือทุก ๆ ทีม รวมทั้งทีม PO ควรจะอยู่ในบริเวณเดียวกัน (ฺBig Room) เพื่อให้ทุกคนอยู่ใน บริเวณที่ง่ายต่อกรสื่อสาร ถ้ามีประเด็นอะไรที่เกี่ยวข้องกับ PO ทุก ๆ ทีม ก็สามารถยกมือถามได้เลย ณ ตอนนั้น หรือกรณีที่มี Feature บางตัวที่เกี่ยวข้องกัน หรือมีส่วนที่จะกระทบกับทีมอื่น ก็สามารถที่จะรวมกลุ่ม หรือเรียกคุยร่วมกันได้ ณ ตอนนั้นเลย เพื่อประหยัดเวลา และลด Feedback Loop นั่นคือถึงเราจะพยายามลด Cost ที่อาจจะเกิดจาก Communication แต่ Communication ในทีมใหญ่เป็นสิ่งจำเป็นมาก การ Split แล้วทำไปพร้อม ๆ กันอยู่บริเวณเดียวกันจึงเป็นทางออกที่จะมา Balance มันได้

Product Owner ทำหน้าที่อะไร

จริงอยู่ว่าใน Scrum กำหนดบทบาท Product Owner ขึ้นมาให้มีคนตัดสินใจเพียงคนเดียว แต่ก็ไม่ได้หมายถึงคน ๆ นั้นจะไม่มีทีมงานอยู่เบื้องหลัง เมื่อ Product มาถึงจุดที่ใหญ่ขึ้นมาก ๆ การให้ความสำคัญกับบทบาทของ PO ย่อมสำคัญมากขึ้น การที่มี Feature ที่ต้องทำเยอะขนาดที่ไม่สามารถผลิตได้ทันด้วย Development Team เพียงทีมเดียว ก็เป็นตัวบอกแล้วว่า Requirement หรือ Feature ที่ Product ต้องรองรับได้ย่อมมีจำนวนมากขึ้น ซึ่ง PO คนเดียวไม่สามารถที่จะลง Detail กับ Feature ทุกอันได้ เพราะฉะนั้นหน้าที่ความรับผิดชอบในการ Clarify และ Confirm Requirement จึงถูกส่งต่อ ให้กับ PO Team และ Development Team เพื่อทำให้ Development Team ได้มีโอกาสเก็บข้อมูลโดยตรงจากผู้ใช้ หรือผู้มีส่วนเกี่ยวข้อง แล้วให้ PO มา Focus ที่ ฺBusiness Value วิธีการการลงทุน และความคุ้มค่าที่จะได้จากการทำแต่ละ Feature ออกมาสู่ตลาด เพื่อให้ทุก ๆ เวลาที่เสียไปกับการสร้าง Product นั้น ๆ ได้ผลตอบแทนตามเป้าหมายอย่างสูงสุด

ส่วนสำคัญ และส่วนอื่น ๆ ที่ต้องระมัดระวังเมื่อ ขนาดของทีมใหญ่ขึ้น

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

  • Goal : การสื่อสารเพื่อให้ทุกคนรู้ถึง Goal ของ Product ยาวไปถึง Goal ระดับย่อยของแต่ละ Sprint หรือแต่ละ Feature เพื่อให้เข้าใจภาพตรงกันและเดินไปในทิศทางเดียวกัน
  • Communication : นอกจาก Communication ระหว่างทีมงานเช่น User, PO Team และ Development Team แล้วการสื่อสารกันระหว่าง Developer ก็เป็นเรื่องสำคัญ ไมว่าจะเป็นการพยายามที่จะสื่อสารกันอยู่ตลอด ในกรณีที่ทำงานเกี่ยวข้องกัน รวมไปถึงการสื่อสารผ่าน Source Control Tools ก็เป็นสิ่งที่สำคัญมาก
  • Integration : พยายามให้ทุก ๆ ทีม Integrate กันบ่อย ๆ เพื่อให้เกิดการสื่อสารกัน ระหว่าง Development Team ไม่ใช่ว่ารอ Integrate กันตอนหลัง ๆ
  • Engineering Practices : สิ่งสำคัญของการทำ Team ที่ใหญ่คือการแทรก Engineering Practices  เพื่อสร้างรากฐานที่ดีในการทำงาน “Business Agility rely on Technical Agility”

สรุปแล้วอะ

เขียนต่ออีกคงยาวขอตัดจบไว้ตรงนี้ก่อนดีกว่าครับ แต่พอผมมาอ่าน ๆ สิ่งที่ตัวเองเขียน ๆ ออกมาแล้ว ก็เริ่มรู้สึกได้ว่า จริงอยู่ เนื่องจาก Team ของเราใหญ่ขึ้น การทีเราจะทำให้ทุกคนได้รู้ได้ Sync ข้อมูลไปยังทุกคนเลย ก็เป็นเรื่องที่แพงมาก เราจึงพยายาม Split Team ออกมาเป็นหลาย ๆ  Team แล้วก็หวังว่า ให้หลาย ๆ ทีมช่วยกันทำงานให้ได้ตามเป้าหมายที่ตั้งไว้ แต่จะให้ทุกทีมรู้เท่ากันทั้งหมดเลยก็ยังแพงอยู่ดี เราไม่อยากแบก Cost ของการ Communication เอาไว้ แต่เราหลีกเลี่ยงปัญหาที่อาจจะเกิดขึ้นไม่ได้ การนำ Practices ต่าง ๆ มาประยุกต์ใช้ก็เพื่อ Balanced ระหว่างต้นทุนที่ใช้ ความเร็ว และความคล่องตัวในการทำงาน ยิ่งเราขยายตัวเองให้ใหญ่มากขึ้นเท่าไหร่ยิ่งจำเป็นจะต้องคำนึงถึง คือ Core Value ของแต่ละ Role แต่ละ Activity  ที่เรากำลังทำอยู่เพือให้ประโยชน์สูงสุดบนข้อจำกัดที่มีอยู่ …

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